This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Fabio Pietrosanti (naif) lists at infosecurity.chOn 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 follow: PC->Serial->Modem->VoIP ATA->Asterisk-> GSM-VoIP-Gateway->GSM Voice call(4.75-to-13kbit)->Telephony-network-PSTN-modem(64kbit) 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 support 1200bit/s). > 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 4.75kbit) ? 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! :) -naif -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20110115/a9338f99/attachment.htm>