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
PC->Serial->Modem->VoIP ATA->Asterisk-> GSM-VoIP-Gateway->GSM Voice
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
> 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
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! :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel