running voice data/encryption on compal?
wesley.tanner at gmail.com
Sat Jan 15 00:15:16 UTC 2011
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.
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). 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.
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.
At any rate it is an interesting problem.
On Fri, Jan 14, 2011 at 2:50 PM, Fabio Pietrosanti (naif) <
lists at infosecurity.ch> wrote:
> On 14/01/11 21.29, Harald Welte wrote:
> > Aaron,
> > the usual problems with end-to-end encryption in GSM come into play:
> > * as the voice path is not transparent but transcoded any number of times
> > in the core network, you cannot simply encrypt the codec frames but
> > have to initiate a CSD ('modem') connection.
> Enciphering directly the GSM/AMR codec payload at GSM it's still a cool
> hackish idea!
> Regarding transcoding it's also to be considered that within the same
> operator or at GSM inter-working national level it's much more difficult
> that transcoding it's done in the voice path.
> Mobile operators tends to avoid transcoding whether possible to reduce
> the infrastructural costs associated with media gateway equipments and
> directly interconnected mobile operators probably doesn't do much
> I asked you a similar question at ph-neutral a couple of years ago and i
> remember that there's also an issue related not being able, due to
> hardware design of baseband, to control the path between the
> encoder/decoder and the transmitter.
> So no "hands on" the audio encoded/decoded payload that will get sent to
> the network, right?
> > * not many networks support it anymore
> > * calling rates are more expensive
> > * you immediately leave a visible trail, since nobody else uses CSD
> > And no, neither is the ARM7 fast enough for any crypto, nor do we
> > CSD at all.
> We all would really like to see incredibly efficient DoV (Data over
> Voice) modem technologies reaching at least stable 800bit/s to be able
> to run a 600bit/s audio codec along with some encryption on top of it.
> For military stuff there's a UK university that made a patent for a
> 1200bit/s DoV with error correction and 0.03% BER over GSM-to-GSM calls
> with GSM codec (13kbit/s).
> Some other DoV has been done to develop emergency services such as
> in-band transmission of information between emergergy services and law
> enforcement operators for european esafety project
> (www.esafetysupport.org) standardizing in-band modem over GSM and AMR as
> 3GPP TS 26.267 but that uber-patented technology are not designed to
> handle realtime transport bust just signaling of messages.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel