[Asterisk-Dev] High-Bandwidth codecs (again) G.722.1

[John Todd]

At 8:57 PM -0400 8/6/05, asterisk at ntplx.net wrote:
>
>Quoting John Todd <jtodd at loligo.com>:
>
>>
>>  There has been discussion here about the complexities of adding
>>  high-bandwidth codecs to Asterisk which use Asterisk's ability to
>  > insert/examine/redirect media flows.
>
>I won't requote the whole email....but I have G.722 running now supporting
>Grandstream BT phones. I don't have a codec translator working yet so G.722
>only works between phones. G.711 is still used for other calls.
>
>Note this is G.722, not G.722.1 or G.722.2. I'll look at the polycom stuff
>for G.722.1 it seems like it might be a good solution. The grandstream is
>not a very good phone so I can't hear much improvement on G.722 vs. G.711.
>
>The simple answer for Asterisk on high sample rate (ie 16Khz) audio
>is don't worry about it....G.722 (original) was designed for 64K ISDN
>so in it's natural form we pass it off just like G.711 64K...no problem.
>I have G.722 file format working fine too because it uses the same
>setup as G.711. I have not looked at making lower bandwith (56K, 48K, etc)
>verions working as I don't have a better test phone.
>
>As for what do to with 16k audio....downsample/upsample. If someone
>is not using the native G.722 codec then who cares if the codec translates
>down to a 8Khz format. At least for now it would work, 16Khz SLin audio
>can be added later (much later) if ever needed. It would only buy you
>higher quality voicemail/MOH/meetme...not very important at this time.
>
>If two phones use G.722 at 64K then asterisk does not have to do anything
>special to pass the audio data.
>
>   Andrew
>


 From my experiences, it seems that the most critical time to have 
high-quality voice is on conference calls, but getting it working 
endpoint-to-endpoint is the first good step.

I assumed that Asterisk would handle "native bridged" SIP calls with 
G.722 (or G.722.[1,2]) without difficulty, since the media flow goes 
between the two endpoints, or passes through Asterisk with no 
modification (though this would probably still require a few hacks, 
since Asterisk seems to care what's in the SDP payload more than it 
should.)

If you've got any ambition to develop a transcoder/translator for 
G.722.1 Annex C, then put your ideas forward for perhaps other 
developers to discuss - the fact that we're stuck (at best) with 
telephone-quality audio is kind of depressing considering what we 
could possibly be doing (stereo 16hkz 16-bit conference calls, 
anyone?)

Digium et. al.:  Does anyone have a real lawyer they could ask about 
the license terms and how it might apply to inclusion in Asterisk?  I 
don't think it would ever be able to go into any of the "official" 
distribution packages or CVS trees, since Digium has special 
disclaimers for that code, but perhaps it could be a separate plug-in 
downloaded from a different location?

JT