On 15/01/11 01.15, Wesley Tanner wrote:
Hi all,

This particular problem domain is why I originally became interested in this project. In fact I just bought a couple C118s and now have them running the current build as of yesterday.
Wow, that's extremely interesting!

Some time ago i made an extremely no-so-technologically-advanced test.
I got a friend's old us robotics sportster 14.4k modem, connected to an VoIP ATA, connected to an Asterisk, connected to a GSM VoIP Gateway as follow:

PC->Serial->Modem->VoIP ATA->Asterisk-> GSM-VoIP-Gateway->GSM Voice call(4.75-to-13kbit)->Telephony-network-PSTN-modem(64kbit)

Made calls to a PSTN dialup modem and was able in a GSM-to-GSM calls to get 300bps modem carrier.
But that's very very dirty tests not even entering into DSP specific issue to make a DoV modem!

There has been additional work done in the academic world on "data-over-voice" the last few years, mainly out of Chinese and Iranian universities. Some of them claim reliable data rates of 2000 bps or higher (not including error correction), which is good enough for low data rate vocoders (e.g. speex).
I immagine that in a real world scenario it would be required something even more ultra-narrowband than speex, like the ones destinated for use in HF radio/military world would be required.
Something like NATO STANAG 4479 (800bit/s) or MELPe (600/1200/2400) or MELP (1200/2400) or CDMA EVRC-B (800bit/s) or future CODEC2 (that will support 1200bit/s).

A search on IEEE comes up with a bunch of papers, and some have fairly detailed design data. Most are optimized for EFR, and some for AMR. Some claim to be computationally efficient enough for implementation on modern smart phones.
Well, but practically on a smartphone how to specify to use GSM EFR (giving at least 12.2kbit) respect to AMR (that can go down up to 4.75kbit) ?
Having an higher bitrate codec forced would improve the stability and performance of such as data over voice modem.

So far, the modems have been implemented at the audio interface of the handset, not the raw OTA compressed voice frames. I believe a project such as this will make it possible to improve these modems by being able to directly control the content of the traffic frames. At the very least, I think it will aid in synchronization issues between the end points, and easier handling of VAD/DTX/CNG.

The problem is made very difficult because of transcoding done within the network. And, depending on the call, there may be different transcode operations between end points (or maybe none at all?). Also, the voice frame parameters are not all protected equally from channel errors. My hope was to actually start characterizing network transcode behaviors, since I have not yet found any real data on this. It is possible to do this without access to the traffic frames, but it makes for more complex test cases.
Well, probably also targeting very reduced rates such as 800bit/s could improve the ability to works across more transcoding.
Some times ago i spoke with airbiquity that make this aqlink uber-patented technology that claim to be able to do 800bit/s even over AMR codec www.airbiquity.com/pdf/productsheets/aqLink.pdf .

A 600bit/s audio codec plus some protocol overhead on top of a powerful DoV modem running at least at 800bit/s would make probably a new way to make voice encryption over everything that's a voice channel!

A dream! :)

-naif