<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 15/01/11 01.15, Wesley Tanner wrote:
    <blockquote
      cite="mid:AANLkTiniyvVwJmgO-LmfWjR+WTNeBH-L2PYDMKMGVxi6@mail.gmail.com"
      type="cite">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>
    </blockquote>
    Wow, that's extremely interesting!<br>
    <br>
    Some time ago i made an extremely no-so-technologically-advanced
    test.<br>
    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:<br>
    <br>
    PC->Serial->Modem->VoIP ATA->Asterisk->
    GSM-VoIP-Gateway->GSM Voice
    call(4.75-to-13kbit)->Telephony-network-PSTN-modem(64kbit)<br>
    <br>
    Made calls to a PSTN dialup modem and was able in a GSM-to-GSM calls
    to get 300bps modem carrier.<br>
    But that's very very dirty tests not even entering into DSP specific
    issue to make a DoV modem!<br>
    <br>
    <blockquote
      cite="mid:AANLkTiniyvVwJmgO-LmfWjR+WTNeBH-L2PYDMKMGVxi6@mail.gmail.com"
      type="cite">
      <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). </div>
    </blockquote>
    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. <br>
    Something like NATO STANAG 4479<span class="tl"> (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).<br>
    </span><br>
    <blockquote
      cite="mid:AANLkTiniyvVwJmgO-LmfWjR+WTNeBH-L2PYDMKMGVxi6@mail.gmail.com"
      type="cite">
      <div>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>
    </blockquote>
    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) ?<br>
    Having an higher bitrate codec forced would improve the stability
    and performance of such as data over voice modem.<br>
    <br>
    <blockquote
      cite="mid:AANLkTiniyvVwJmgO-LmfWjR+WTNeBH-L2PYDMKMGVxi6@mail.gmail.com"
      type="cite">
      <div>
        <meta http-equiv="content-type" content="text/html;
          charset=ISO-8859-1">
        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>
    </blockquote>
    Well, probably also targeting very reduced rates such as 800bit/s
    could improve the ability to works across more transcoding.<br>
    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 <span class="f"><cite><a class="moz-txt-link-abbreviated" href="http://www.airbiquity.com/pdf/productsheets/">www.airbiquity.com/pdf/productsheets/</a><b>aqLink</b>.pdf
        .</cite></span><br>
    <br>
    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!<br>
    <br>
    A dream! :)<br>
    <br>
    -naif<br>
  </body>
</html>