Re: Secure voice software issues
Phil Karn <karn@qualcomm.com> wrote: [Re: squeezing 13.3 kbps data w/o start&stop bits over modem]
Whenever V.42 error correction (LAPM) is enabled, synchronous HDLC frames are what actually pass over the link. So the start/stop bits are already removed.
Unfortunately, the packetizing done by LAPM adds delay we don't want for a real time voice application. And if you turn off LAPM, you return to sending the start/stop bits over the wire.
Well... How much latency does LAPM really add? Little enough that full duplex keystrokes echo back nearly instantly on my connections. People talk over satellite links with more delay than that all the time. Since we're not going to get toll quality voice out of the vocoders anyway, and the error correcting stuff is especially useful for encrypted data streams... I think V.42 is probably a good idea for a cryptophone project.
Most V.32 and V.32bis modems provide for direct synchronous operation, which would let us have our cake and eat it too, except that few PCs can speak synchronously to a modem. This may require some extra hardware (sigh).
I'm in favor of getting a minimal version that will run on the lowest common denominator hardware first. (Might have something to do with the fact that I just spent a couple hundred dollars on an internal V.32bis modem that doesn't do synchronous :^) Joe
I see 160ms round trip times on my SLIP link from home to work, and I can't account for all of this time by just adding up transmission times and store-and-forward delays for the data rates and packet sizes I'm using. And I don't think it can be explained by the trellis decoding in V.32 bis, as that should account for only a few bits of delay. I've since heard of very similar figures for other modems, so It's not just my modem. I'm beginning to suspect the V.42bis packetizing algorithms. Although they're not described in the spec, I suspect that real V.42bis implementations use timers to determine when to send the the currently queued data as a frame. Or maybe there's a Nagle-like algorithm like the one in TCP: immediately send the first byte of data on an idle link, but keep additional traffic pending until the first byte is acknowledged in order to aggregate stream traffic into larger frames. This is all speculation so far, but it does explain the long RTTs I see with packet traffic even though raw character-at-a-time traffic seems to be fast. Stream traffic would see the worst delays of all, which is ordinarily okay for a file transfer, but death to a real time stream like voice. That's why we may be forced to turn off V.42 entirely and speak synchronously to the modem. Time to haul out a protocol analyzer and do some timing measurements. Phil
participants (2)
-
jthomas＠kolanut.mitre.org -
karn＠qualcomm.com