ecsl@netbloc.com: 9711: Telephony

Subject:
From:
Date:

Telephony
Richard V.C. Tinker
Mon, 27 Nov 2000 09:36:27 -0500

Mon, 27 Nov 2000 09:36:27 -0500

Folks,

After reviewing some of the telephony/voicemail messages that have come
across the list the past few months, I felt it would be best if I list some
of the things that caused me much bruising while I worked for HAL w/r/t
modems.

1. Mark's idea of passing the audio to/from the voice modem and the sound
board is exactly what the current released version of HAL2000 does today.
The problems with it are too numerous to list, but here are some of the top
ones:  A. Audio quality typically sucks.  B. Some sound boards cannot be
modified for unamplified (e.g. line level) output, which is what you need in
order to be able to connect it to the mic input of the voice modem, and THEN
you need an stereo audio connector "Y" adapter and amplified speakers to
hear anything out of the sound board.  Conversations over the telephone will
be heard over the speaker as well unless the software manages communicating
with the sound board's software mixer (and they are not all compatible with
the Microsoft provided interface to the mixer) so that the LINE IN or
whatever is used to accept the audio from the voice modem can be muted when
not in use.

2. Good quality audio comes from getting it directly from the data bus of
the modem - e.g. WAV audio direct from the voice modem.  Contrary to popular
belief, that does not automatically mean TAPI.  You can send/receive WAV
audio with the voice modem using standard AT commands.  If the programmer is
especially sharp (let's see if Mark can take the bait on that one) then it
can be done in full-duplex mode with many of today's modems.

3. Extensibility, or in layman's terms the ability to modify the program
somewhat on-the-fly is what would allow the software to work with different
modems.  At HAL, I implemented that through the use of modem AT commands
that are stored somewhere and then loaded by the software as it starts.
That way, if we wanted to change how a particular modem is supported or add
support for a new modem, a program could be run that simply loads new AT
commands in the modem string storage area.  Mark has had that concept for a
long time in Phone-C.set (or whatever the file name is) but it did not go
far enough, and documentation of the commands was abysmal (sorry Mark).

4. Limitations of TAPI were a big pain in the butt.  One of them was that
with HAL2000, you can pick up any phone in the house, press #, and then talk
to HAL.  We could find modems that still had the local handset
on-hook/off-hook detection circuitry on them (although it was hard), but
those that had TAPI support required that the phone be on-hook before it
could be put into the local handset audio mode for two-way audio.  This
meant that the user would have to pick up the local handset, press # (or
some other key), hang up, wait a second or two, and then pick up the phone
again to talk to HAL -- unacceptable.  Thus, HAL worked with modem
manufacturers for the newer modems that had this as a hardware requirement
(small change in the firmware fixed it) and then wrote custom AT command
software to get around the same limitation in TAPI.  There were a few other
limitations of TAPI w/r/t the local telephone handset as well - it is a
great deal different from the remote handset.  Believe me when I say that if
local telephone handset worked as well as remote, then many of you would be
using your telephone to issue commands to your ECS system.  The big
limitation here is that local handset DTMF tones are not reported as they
are pressed typically - you have to hang-up before the modem reports the
DTMF keys that you pressed while it was off-hook!!  TAPI 3.0 is suppose to
remove all of these limitations, but TAPI 2.0 was suppose to fix a bunch
that it did not address as well...


So to summarize, I'd say that TAPI brings 3 main features to an
application - 1. It allows multiple programs to use the same modem (e.g. ECS
and Dial-up Networking could both use the same modem), 2. It provides a
standard interface so that many different modems will work with it without
the programmer having to know the modem, and 3. It provides a good quality
digital audio interface to the voice modem.   At HAL, we wrote our own modem
interface because we provided our own software solution for the standard
interface mentioned by #2 above, write our own software to use the same
audio interface in #3, and while we could not find a way to reproduce the
modem sharing feature #1 speaks about, we also did not have to live with the
common-denominator solution TAPI 2.0 was providing.

My suggestion would be for somebody to get the skinny on the deployment of
TAPI 3.0 w/r/t the operating systems out there (Linux will be the tough one)
and use that if it is going to happen soon, and if not to go ahead and do
something like what HAL did to significantly improve the telephony features
of ECS.


Sorry if this was a little more verbose than your typical ECS posting, but I
am hoping it will spawn some good discussions.



Regards,


Rick

Folks,

After reviewing some of the telephony/voicemail messages that have come across the list the past few months, I felt it would be best if I list some of the things that caused me much bruising while I worked for HAL w/r/t modems.

1. Mark's idea of passing the audio to/from the voice modem and the sound board is exactly what the current released version of HAL2000 does today. The problems with it are too numerous to list, but here are some of the top ones: A. Audio quality typically sucks. B. Some sound boards cannot be modified for unamplified (e.g. line level) output, which is what you need in order to be able to connect it to the mic input of the voice modem, and THEN you need an stereo audio connector "Y" adapter and amplified speakers to hear anything out of the sound board. Conversations over the telephone will be heard over the speaker as well unless the software manages communicating with the sound board's software mixer (and they are not all compatible with the Microsoft provided interface to the mixer) so that the LINE IN or whatever is used to accept the audio from the voice modem can be muted when not in use.

2. Good quality audio comes from getting it directly from the data bus of the modem - e.g. WAV audio direct from the voice modem. Contrary to popular belief, that does not automatically mean TAPI. You can send/receive WAV audio with the voice modem using standard AT commands. If the programmer is especially sharp (let's see if Mark can take the bait on that one) then it can be done in full-duplex mode with many of today's modems.

3. Extensibility, or in layman's terms the ability to modify the program somewhat on-the-fly is what would allow the software to work with different modems. At HAL, I implemented that through the use of modem AT commands that are stored somewhere and then loaded by the software as it starts. That way, if we wanted to change how a particular modem is supported or add support for a new modem, a program could be run that simply loads new AT commands in the modem string storage area. Mark has had that concept for a long time in Phone-C.set (or whatever the file name is) but it did not go far enough, and documentation of the commands was abysmal (sorry Mark).

4. Limitations of TAPI were a big pain in the butt. One of them was that with HAL2000, you can pick up any phone in the house, press #, and then talk to HAL. We could find modems that still had the local handset on-hook/off-hook detection circuitry on them (although it was hard), but those that had TAPI support required that the phone be on-hook before it could be put into the local handset audio mode for two-way audio. This meant that the user would have to pick up the local handset, press # (or some other key), hang up, wait a second or two, and then pick up the phone again to talk to HAL -- unacceptable. Thus, HAL worked with modem manufacturers for the newer modems that had this as a hardware requirement (small change in the firmware fixed it) and then wrote custom AT command software to get around the same limitation in TAPI. There were a few other limitations of TAPI w/r/t the local telephone handset as well - it is a great deal different from the remote handset. Believe me when I say that if local telephone handset worked as well as remote, then many of you would be using your telephone to issue commands to your ECS system. The big limitation here is that local handset DTMF tones are not reported as they are pressed typically - you have to hang-up before the modem reports the DTMF keys that you pressed while it was off-hook!! TAPI 3.0 is suppose to remove all of these limitations, but TAPI 2.0 was suppose to fix a bunch that it did not address as well...

So to summarize, I'd say that TAPI brings 3 main features to an application - 1. It allows multiple programs to use the same modem (e.g. ECS and Dial-up Networking could both use the same modem), 2. It provides a standard interface so that many different modems will work with it without the programmer having to know the modem, and 3. It provides a good quality digital audio interface to the voice modem. At HAL, we wrote our own modem interface because we provided our own software solution for the standard interface mentioned by #2 above, write our own software to use the same audio interface in #3, and while we could not find a way to reproduce the modem sharing feature #1 speaks about, we also did not have to live with the common-denominator solution TAPI 2.0 was providing.

My suggestion would be for somebody to get the skinny on the deployment of TAPI 3.0 w/r/t the operating systems out there (Linux will be the tough one) and use that if it is going to happen soon, and if not to go ahead and do something like what HAL did to significantly improve the telephony features of ECS.

Sorry if this was a little more verbose than your typical ECS posting, but I am hoping it will spawn some good discussions.

Regards,

Rick