Anrufbeantworter mit Hagenuk Speed Dragon?

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

   From: gert@greenie.muc.de (Gert Doering)
   Date: Mon, 6 Jul 1998 17:21:11 +0200 (MEST)

   David Kastrup wrote:
   >    Well, maybe not the latter, but definitely the former.  There is no CAPI
   >    support in vgetty.  Adding one would require writing a low-level driver
   >    for the Speed Dragon which provides the interal vgetty API on top of
   >    this "AT-command-CAPI". 
   > 
   > Uhm, I guess you misunderstood.  The Speed Dragon *either* provides
   > the basic functionality via AT-mode commands, *or* a complete
   > implementation of CAPI-2.0 via the serial line.  As I am not aware of
   > any efforts under Linux to work with CAPI, I was asking about how to
   > work with the AT-command options.  

   Well, if it doesn't *have* AT commands for voice, you *have* to use CAPI,
   if you like it or not.

   How do you propose to do voice if the Speed Dragon doesn't have AT
   commands and you do not want to do CAPI?

Sigh.  I already explained before that it *does* have AT commands for
voice, just not the usual AT+ command set expected from vgetty.  When
you get a voice call, it is announced as such by a service number in
the RING message, and you can simply answer it with ATA as you would a
data call, after that transferring voice material transparently and
bidirectionally in the obvious way, presumably in the obvious way
until one of the partners hangs up, which would be indicated by a drop
of DCD or caused by a drop of DTR.

This would be far more simple than trying to use a complete CAPI
interface, I guess.  Using the CAPI would also have the disadvantage
that I would have to kick Hagenuk into specifying just *how* they
encapsulate their CAPI2.0 messages on the serial line (or find that
out by packet sniffing while running the stuff under W95)).

   > I have already looked at the vgetty
   > code and have gathered the impression that the internal vgetty API
   > *requires* a basic AT+ voice command support, and only the more
   > specific details of individual modems get encapsulated into the
   > various modem specific files.

   AFAIK, no.  You have to have something that follows the general
   programming model of a voice modem, but I think that it should be possible
   to write a low level driver that works on top of some kind of CAPI
   interface.

Well, as said, I'll be happy to be proved wrong, as the basic
functionality of kicking the Hagenuk Speed Dragon into transparent
bidirectional speech mode via the AT interface seems easy enough
(although non-standard).  One difference would be that you don't tell
the Hagenuk about your compression, but it tells you instead what sort
of voice input you get from an incoming call (the calls I put through
from my own analogue lines were indicated as "3.5kHz voice" or
similar.  There are also things like "7kHz voice" and other stuff).
You can tell it on outgoing calls what protocol it should be using,
but I don't know whether the Telekom (or whoever else is going to
interpret the digital variant) will accept all of the different
quality settings.  You get a busy signal, BTW, if nobody is going to
be able to to anything with the particular "CIP" service you offer on
your outgoing call.

Quite a bit of experimentation will be needed to get things figured
out properly, of course.

And in case people think the entire endeavour feasible, I will of
course pester Hagenuk to the maximum degree with requests for more
information than delivered already with the box (the basic AT mode
description, which leaves out quite a few details and examples and is
mostly enough to get the thing working for in- and outgoing Dialup
PPP).

BTW, does anybody have the definition of DTMF tones?  I suppose that
for proper voicebox interaction I would want to detect them on the
analogue data, and I am not sure whether the box would somehow detect
those.

If nobody knows about DTMF definitions, this should not be overly
tragic, as I suppose they can be found with some simple
autocorrelation techniques from incoming data.

At least for this purpose having the Speed Dragon will be handy: as I
can make almost all experiments via internal connections, I need not
pay the Telekom for that.

David Kastrup                                     Phone: +49-234-700-5570
Email: dak@neuroinformatik.ruhr-uni-bochum.de       Fax: +49-234-709-4209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany