We have discovered that recommending specific voice modems is very difficult. The problems began as soon as we started posting voice modem names and model numbers on our web site. Customers and prospects alike could not find the devices. It seems the various models would be gone as quickly as they appeared. Sometimes replaced by a similar model - newer, cheaper, but frequently lacking previously working features. Sometimes although the model number did not even change, what was actually in the box did. Therefore we, no longer provide a list of recommended voice modems.
Please Note: We do not recommend specific voice modems. We have tried those listed below (and many others) and have not found any voice modems which we feel are well suited to voice applications. We are not recommending the voice modems listed here and are not suggesting they will perform in your computer, with your telephone lines, or for your application the same as they do at our location. Please, if you are serious about your project and want to save considerable time and frustration ask us about true voice telephony devices that would be more appropriate for your needs.
To provide support for the Windows Telephony API (TAPI), modems use Microsoft's Unimodem or UnimodemV as their TSP (Telephony Service Provider or driver). To achieve acceptable functionality and reliability, most voice telephony devices (other than modems) use a TSP that was developed specifically for that device. At the time of this writing we are aware of no modems that provide their own TSP.
When a modem is installed Windows uses the INF install files (provided with the modem) to create information in the System Registry. This information includes the commands and responses for the modem and is used by Unimodem to determine the capabilities of, and how to communicate with the modem. In general the INF files are supplied by the modem manufacturer.
You should check with your modem manufacturer to see
if they have updated INF files for your modem. In many cases updated INF files available on
the modem manufacturer's web site. From time to time
manufacturers will update these files so be sure to check regularly,
even if your modem is brand new!
Here is a list of sample programs written specifically for the voice modems:
Many modems have poor audio quality and / or poor play and record quality
Since modems usually fire the OnConnected event immediately after dialing the number, sometimes modems miss firing the OnBusy event entirely, or they will fire it after the OnConnected event fires. In addition, modems are usually designed to detect tones for a specific geographic region. Thus, a modem designed to respond to phone signals in the US may not work properly in the UK.
Most modems do a pretty good job detecting Caller ID, but only in the geographic region the modem was designed for, and only if the INF file, which is often incorrect, has the right settings. North America uses the Bellcore FSK Caller ID standard which sends the data between the first and second ring, while some other countries use the ETSI DTMF or FSK standard which sends the data before the first ring. Some modems (like some US Robotics models) cannot detect caller ID in voice mode because the FSK data is coming in at a rate that the modem was not designed to accomodate. There is a device on the market that can convert DTMF or ETSI FSK Caller ID information into Bellcore Caller ID FSK, it is called the EX200 CallerID Converter from a company called Artech. In Europe, people have reported success with USR model number 5630. For more information check the UK Caller ID FAQ.
If you are having problems with Caller ID, here are some steps you should take to help isolate the problem.
1. If you have some other Caller ID device (like a phone with a Caller ID display or a independent Caller ID display box) try attaching that to the telephone line of interest to ensure the line supports Caller ID.
2. Are the modems you are trying to use voice modems? Typically data or data/fax modems do not report Caller ID through TAPI.
3. If you are using voice modems you will need to ensure that they support the type of Caller ID signaling that is being sent on that line. As explained above, this is typically either FSK or ETSI DTMF and is reported either before the first ring or between the first and second ring. Check with the modem manufacturer and your telephone line provider to see if your modem model supports the signaling provided on that line. If you are behind a PBX or key system, you will need to check with that system's manufacturer to see if (and what type) Caller ID features are supported on the analog station lines.
4. If all the above check out OK, then the problem may be in the INF (installation file) provided by the modem manufacturer. Check with the modem manufacturer for updated INF files or to help further debug the issue.
While some modems can reliably monitor digits, or detect the DTMF tones, they typically cannot use the gather digits command. This means that you have to process each digit separately, possibly dropping digits, instead of the device buffering the received tones and you processing them as a single string. Please see our etGatherDigitsWorkaround sample program for how to emulate this feature with a modem.
Some modems have unreliable DTMF detection. Your user enters their password of "1234" and the modem and driver combination report back to your application "#59*6". In addition, modems do not properly report the LINECALLFEATURE_MONITORDIGITS flag set in the property etLine.Address.Capabilities.CallFeatures. So you can't check to see if the modem supports DTMF digits without direct testing and making sure the INF file is correct.
Another thing to keep in mind is that even if the software that comes with your voice modem appears to perform some of the functions that you wish to implement, they may be accomplishing that by writing around TAPI. In other words, many of the bundled applications that come with voice modems write directly to the hardware and bypass TAPI! Not only can't you access the features of your modem with your TAPI application, but if hardware direct software is running on that machine, it will interfere with any TAPI compliant applications.
The INF file is supposed to contain an accurate reporting of device capability. Unimodem and TAPI query the information reported at installation time by the INF file to find out things like "does this modem support a wave device?", "does this modem have speakerphone capability?", "does this modem support caller id?". Sadly, almost all modem manufacturers misreport information in the INF file. Modems report capabilities they do not have and do not report capabilities the do have.
Modems are limited by their TSP (UnimodemV) to only being able to handle one call. If you are connected to a line with 3-way calling, you can do tricks like we have done with our etThreeWayFlash Sample Program to switch between 2 call and create a 3-way conference, but you have no way of tracking the calls. In addition, you have no way to answer an incoming call while you are on the line, because the modem will not recognize the callwaiting beep.
Most voice modems do not have drivers that support multiple modems of the same type in the same machine. You can either find a modem that does, re-write the INF files, use two different modems from different manufacturers, or use a true telephony device. You can contact ExceleTel support for workarounds to the these problems
Voice modems are not capable of outbound Call Progress Monitoring (CPM). Therefore the etLine.OnConnected event is called immediately after dialing is complete. This is the event that you would normally use to indicate that something or someone answered the call. Therefore, software cannot detect when an outbound voice call is answered. This can also sometimes block the detection of the busy signals.
TAPI supports line devices and phone devices. The phone device commands allow you to control speakerphones and headsets, along with a telephone handset. Many modems do not support the speakerphone options while none support the headset and handset options. In addition, while there is a jack on voicemodems for connecting a handset, voicemodems do not fire the OnHook and OffHook events to notify you if someone has lifted the handset or replaced it in it's cradle. Voicemodems will only fire the OnPhoneHandsetHookSwitch event when a call is connected! Obviously, this is not very useful. And most importantly, many modems disconnect the handset when the modem goes off-hook or when it is playing a wave file.
Many modems don't provide effective remote hangup detection. That is, when your modem and a remote device are connected in a call, and then the remote device hangs up, your program will not be informed of this via the OnDisconnected event. Some applications may be able to overcome this situation with a timeout or other exception-handling routine based on detecting fast busy, but this is not a robust approach and may prevent you from using modems that have this deficiency.
Modems cannot detect the ringback event. A ringback is the tone your hear on an outbound call letting you know that the called parties phone is ringing. Most applications can get by without needing to detect ringback.
Voice Modems can not detect silence. The error LINEERR_OPERATIONUNAVAIL is generated when the etLine.Call.MonitorSilence.Active is set to True.
If your modem has the word "soft" or "win" in the title, such as "Soft 56k Modem" or "Winmodem 56k" you probably should not even try to use it. These modems are cheap because they offload functions that should be processed on the modem board to your PC processor. The reasons this is not good are too many to list here. Suffice it to say that you should make sure that your modem is a true hardware modem.
If you try to place a voice call on a modem that supports data only, you will see a dialog box that says "Lift receiver and click to Talk / To disconnect click Hang Up and replace receiver." This dialog box is not part of TeleTools. It is an underlying part of TAPI and the Unimodem or Unimodem/V TSP.
Specifically, the following situations cause the dialog box to appear:
To install an updated INF file, remove the modem from Windows, and then reinstall the modem with the new INF. Use Control Panel > Modems to "Remove" and "Add" the modem (use "Have disk" to point to the new INF). Alternatively, for Windows 95 and Windows 98, you can use plug-and-play. If you need help writing your own INF file, ExceleTel consulting services can help.
Voice modems use the UnimodemV Telephony Service Provider (TSP) to interface with Microsoft's Telephony Application Programming Interface (TAPI). UnimodemV is limited to using the wave format "PCM 8000 Hz, 16 Bit, Mono". This is the default format for our etRecord control and all of the wave files supplied with TeleTools are in this format. Other sophisticated telephony devices support a wider range of wave formats.
Other formats may be used if you choose to utilize Windows Wave Audio CODECs. For more information, refer to the white paper Working With WAV Files.
Since modems use UnimodemV as their TSP, and UnimodemV just sends AT commands to the modem to get it to play and record wave files, delays before playing or recording starts can be only a second or sometimes an unacceptable several seconds.
Some voice modems will cause DTMF detection to stop after playing a wave file or even to disconnect a call. Since UnimodemV is a half-duplex driver, you cannot play a wave file and record or do speech recognition at the same time. Some modems will disconnect the handset or the headset when playing or recording a wave file so that you cannot monitor or control the call from your phone.
Voice modems cannot set the volume for playing wave files. You
might be able to overcome for this deficiency with elevated recording
volume levels. This means you may not be able to effectively use some
modems for voice applications that record or play wave files.