I am fairly sure you cannot bypass the amr codec on the device, as the echo cancellation filters in the RNC would distort the datastream if it's not looking enough like speech audio. Anything going down the line needs to be modelled to the range of human audio.

That's basically the reason I haven't really looked too hard at it yet, as it would require some experimenting to find out the modulation sheme that can be passed through without distortion.

These articles show encrypted data over GSM voice chanel is a real possibility already in use on existing phones.
http://www.gsm-modem.de/gsm-voice-encryption.html
http://www.gsm-modem.de/M2M/m2m-faq/...m-voice-lines/
http://www.sciencedirect.com/science...51200408001875
http://www.eurasip.org/Proceedings/E...ers/cr1512.pdf
http://ieeexplore.ieee.org/xpl/artic...number=1497979

This paper is quite intresting as it describes an actual prototype built to implement the encryption & coding.
The requirements of the test system seem fairly modest and should be doable at least on N9 HW, maybe N900 too.

This is relevant to my interests

bump



bump



bump



bump

Stop bumping, start getting your hands dirty and do the work?

This sounds like an intresting task for the free time, anyway corrent me if I'm wrong (and I probably am) but pulseaudio controls witch inputs/outputs are used , and it supports plugins (EQ for example), so my logic is:
If PA supports plugins, and controls the audio streams on the N900, the most easy way to add "encryption call" competability will be by adding a plugin witch does the en/de cryption to PA. (loaded/used only when needed ofc, not all time)
So my question is , am I thinking in the right direction ?

let's get back to work!!!

Just to clarify, this is not meant for general ptsn telephone calls correct?

Unless you get the other side onboard, and they have compatible hardware to decrypt the stream, i don't really see the utility of this, in regards to general ptsn calls.

Don't get me wrong, i think its a great idea, but only for special usage between two parties that have the capability/hardware/know how to set up an encrypted stream. And unless its a cross platform encryption system, it will only work with other n900's.

I'd just go with something like a vpn, and a sip gateway voip service. If you can find service providers for those services that won't bend over for the feds, then add some kind of encryption to the data stream, and your in business.

But once again, it has to be setup/compatible on both ends. If the other end of the call on the ptsn isn't encrypted, theres no vpn/service that prevents wiretapping of the unencrypted ptsn data.

No way around that, unless some kind of universal/cross platform/hardware ptsn encryption system is setup universally. But Uncle Sam wouldn't like that very much, and i don't see it happening anytime soon.

Just to clarify, vpn would allow direct, encrypted sip calls to be made *without* using any VoIP proxy (so-called providers), just direct communication. It is what you meant anyway, probably, but some may mix it up with next sentence about "finding provider, that don't bends to the feds".
---

The interesting idea from this topic, is to use *plain* voice call for encrypted data transfer (at low bandwidth, using tones). This is something I would *really* like to see. Not that it would be replacement for every-day usage, but in case of some problems (like data transfer getting emergency shut down), would be very practical.

Of course, it still require device able to decrypt and encrypt on both sides - but, this time, one of such device could be plain pstn telephone, forwarding received sound to computer (in case of another side lacking N900). Either plain as in "plain", with speaker put to computer microphone, or - more reliable, 5$ PSTN phone modified (super-easy modification) to pass sound into computer line-in, instead of built-in speaker (jack audio output).

Heck, same project - due to code openess - could be used even *without* any N900's, just using computers and mofified PSTN phones.

/Estel

/Edit

I'm pretty sure, that there are some FOSS projects on tonal data transfer already, that could get harvested.