running voice data/encryption on compal?

Fabio Pietrosanti (naif) lists at infosecurity.ch
Sat Jan 15 21:33:01 UTC 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110115/a9338f99/attachment.html>


More information about the baseband-devel mailing list