Hi all,<div><br></div><div>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.</div><div><br>
</div><div>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.</div>
<div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8">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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>At any rate it is an interesting problem.</div><div><br></div><div>-Wes<br><br><div class="gmail_quote">On Fri, Jan 14, 2011 at 2:50 PM, Fabio Pietrosanti (naif) <span dir="ltr"><<a href="mailto:lists@infosecurity.ch">lists@infosecurity.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 14/01/11 21.29, Harald Welte wrote:<br>
> Aaron,<br>
><br>
> the usual problems with end-to-end encryption in GSM come into play:<br>
> * as the voice path is not transparent but transcoded any number of times<br>
>   in the core network, you cannot simply encrypt the codec frames but gqwill<br>
>   have to initiate a CSD ('modem') connection.<br>
</div>Enciphering directly the GSM/AMR codec payload at GSM it's still a cool<br>
hackish idea!<br>
<br>
Regarding transcoding it's also to be considered that within the same<br>
operator or at GSM inter-working national level it's much more difficult<br>
that transcoding it's done in the voice path.<br>
Mobile operators tends to avoid transcoding whether possible to reduce<br>
the infrastructural costs associated with media gateway equipments and<br>
directly interconnected mobile operators probably doesn't do much<br>
transcoding.<br>
<br>
I asked you a similar question at ph-neutral a couple of years ago and i<br>
remember that there's also an issue related not being able, due to<br>
hardware design of baseband, to control the path between the<br>
encoder/decoder and the transmitter.<br>
<br>
So no "hands on" the audio encoded/decoded payload that will get sent to<br>
the network, right?<br>
<div class="im">> * not many networks support it anymore<br>
> * calling rates are more expensive<br>
> * you immediately leave a visible trail, since nobody else uses CSD<br>
><br>
> And no, neither is the ARM7 fast enough for any crypto, nor do we implement<br>
> CSD at all.<br>
<br>
</div>We all would really like to see incredibly efficient DoV (Data over<br>
Voice) modem technologies reaching at least stable 800bit/s to be able<br>
to run a 600bit/s audio codec along with some encryption on top of it.<br>
<br>
For military stuff there's a UK university that made a patent for a<br>
1200bit/s DoV with error correction and 0.03% BER over GSM-to-GSM calls<br>
with GSM codec (13kbit/s).<br>
<a href="http://personal.ee.surrey.ac.uk/Personal/N.Katugampala/pubs/iee04.pdf" target="_blank">http://personal.ee.surrey.ac.uk/Personal/N.Katugampala/pubs/iee04.pdf</a><br>
<br>
Some other DoV has been done to develop emergency services such as<br>
in-band transmission of information between emergergy services and law<br>
enforcement operators for european esafety project<br>
(<a href="http://www.esafetysupport.org" target="_blank">www.esafetysupport.org</a>) standardizing in-band modem over GSM and AMR as<br>
3GPP TS 26.267 but that uber-patented technology are not designed to<br>
handle realtime transport bust just signaling of messages.<br>
<font color="#888888"><br>
-naif<br>
<br>
</font></blockquote></div><br></div>