Intercepting Audio == Freedom from Service Providers

[Andreas Kostyrka]

* Bryan Fink <bryan.fink at gmail.com> [070113 15:32]:
> On 1/13/07, Andreas Kostyrka <andreas at kostyrka.org> wrote:
> >> If your phone can receive data over a voice channel, you have less of
> >> a reason to pay your service provider for a separate "data package".
> >> This would be especially nice for someone like me who only subcribes
> >> to the "bare bones" plan, but still has minutes left over at the end
> >> of the month and has to pay $.50 for the five text messages received.
> >> (Sure, only useful when communicating with other OpenMoko users, but
> >> still a possibly useful feature.)
> >
> >The problem is, that sending raw data is probably not possible.
> 
> Ha!  Possible, schmossible.  With that attitude you'll fail before you begin.

Nope, the problem is that mobiles are highly regulated gadgets. Sure
way to fool around them to get into legal troubles.

> 
> >*) trying to send data via the audio channel is doomed on two counts:
> >first you need a software modem, and these are not free software, plus
> >you would need to take into account the fact that the GSM module does
> >apply all kinds of lossy compression on the audio data.
> 
> A) Software modems can be written - that's the point of an open source
> phone.  See B for one example.  I'm sure someone much more clever than
> me could come up with something much better.

In theory yes. In practice, as this is even a harder problem than
normal modems, I'd like to see a free softmodem codec first. Notice
that the opensource community was not able to come up with something
working in over a decade. (I mean this stupid Winmodems.)

Additionally, you need to consider that this stuff is most certainly
protected by huge list of patents :(

> 
> B) Even with lossy compression, there are still plenty of methods of
> sending data.  I've mentioned one already - Morse code.  I've seen so
> many term-long class projects implement Morse code encoder/decoders
> over crappy transmission channels, it's not even funny.  Simply find a
> carrier and transmission rate that the gsm module doesn't mangle "too
> bad", and you're golden.
> 
> "But Morse code only sends text!" you claim?  Simple: uuencode your
> raw data first (or use any other binary-to-text encoding, of course).
> Throw some parity/hashes on the end to catch errors.
No problem here. The problem is the bandwidth. Technically one could
communicate (although regulations might make it illegal), by caller
id: have n numbers to call from, and never pickup the phone. Added
with with timing one might get some data over the channel.

The problem is, that GSM at best offers a theoretical bandwith of
14400 bps for voice channels. GSM phones switch to lower bandwidth
codecs when the situation requires it.

Now if you are able to use only say 1/10th of the bandwidth because of
your coding stuff. You'll get at best 1440bps. Quality wise one might
notice that this is a connection where despite the propaganda, current
TCP/IP stacks might need adjusting to work. (I had some bad
experiences in this regard, but had never time to trace and debug it
in detail back then.)

1440bps means about 144 bytes per second.

Doing a ping with standard parameter over this link fills it basically
completly.

Let's talk, how long will it take to transfer 1MB. A quick wait of 2
hours will get you 1MB.

Another check, ssh with pubkey to my router generates about 20KB
traffic. Again at this speed, this means about 2.5 minutes before the
prompt of your remote host shows up.

> I never said it would be fast, but it *is* possible...

I never said it would be impossible. I just said, that combined with
my experiences in "mobile internet", anything you might arrive at is
most certainly not worth the effort, just "forget it".

Basically, what's the point of having email at the go, if you would
have it faster by walking to some Internet cafe and starting your
webmail access? Or even ssh-ing into your computer to read it via ssh
(or if it's graphical via vnc-over-ssh).

Additionally, all that doesn't take into account the economic side of
it:

a) first without a real voice flat rate, and there aren't that many,
most plans advertised as "flat" do have some maximum of minutes in the
small print, you cannot be online even with this slow speed online all
the time.

b) it blocks your voice mobile.

c) without being online all the time, you probably need to use it
interactivly. 144B/s is way to slow for sensible feedback in the 1-2
seconds a user might accept to wait.

d) without a flat fee, it all breaks down to a simple question:

   csd_per_minute_cost > (voice_per_minute_cost * slowness_factor)
   
e) all this implies a home station, which means at least one POTS line
blocked while you are communicating.

So basically, to put it into a broken analogy: Is it worth to invest
xx man years of work (hard work, because you don't need a C.S. major,
you need a signal processing engineer, these are rather more seldom)
to get at the end an old and slow Lada, that might be cheaper to
operate than a new car, but in all probability will be more expensive
to operate than other cars?

To close the connection to the topic of this mailing list, you might
end up with a codec that is to complicated to implement in realtime on
a Neo ;) OTOH, the 6th generation Neos that will be available by the
time you get it out sorted, will probably be fast enough to support
such an use *g*


> >The question still staying, how will one access the gsm audio streams?
> 
> ...assuming that is possible, of course. ;)

Well, the HTC mobiles can do that, on one of the virtual tty devices,
when running on Linux. But this is not a HTC design, so it's
interesting how this is solved at the Neo.

Andreas