An example on how to modify your modem driver file to recognize caller id.

This will only work if you modem is caller id capable.

Many modem drivers have an error in them preventing them from displaying the caller id information in the TAPI  mode.  I have found many modem drivers with the following lines:

The following information was provided by Steve Wiley - AirsoftSupply.com.

 

BEGIN WIN2000 MODEMLOG 02-03-2002 01:28:46.453 - File: C:\WINNT\System32\unimdm.tsp, Version 5.0.2175 - Retail 02-03-2002 01:28:46.453 - File: C:\WINNT\System32\unimdmat.dll, Version 5.0.2134 - Retail 02-03-2002 01:28:46.453 - File: C:\WINNT\System32\uniplat.dll, Version 5.0.2151 - Retail 02-03-2002 01:28:46.453 - File: C:\WINNT\System32\drivers\modem.sys, Version 5.0.2195 - Retail 02-03-2002 01:28:46.468 - File: C:\WINNT\System32\modemui.dll, Version 5.0.2146 - Retail 02-03-2002 01:28:46.468 - Modem type: PCTEL Platinum V.90 Modem 02-03-2002 01:28:46.468 - Modem inf path: oem9.inf 02-03-2002 01:28:46.468 - Modem inf section: Modem5 02-03-2002 01:28:46.500 - Opening Modem 02-03-2002 01:28:46.500 - 57600,8,N,1, ctsfl=1, rtsctl=2 02-03-2002 01:28:46.500 - Initializing modem. 02-03-2002 01:28:46.500 - CD is high while initializing modem. 02-03-2002 01:28:46.515 - Send: AT<cr> 02-03-2002 01:28:46.546 - Recv: AT<cr> 02-03-2002 01:28:46.546 - Command Echo 02-03-2002 01:28:46.546 - Recv: <cr><lf>OK<cr><lf> 02-03-2002 01:28:46.546 - Interpreted response: OK 02-03-2002 01:28:46.562 - Send: AT&FE1&C1&D2&K3V1W3S0=0<cr> 02-03-2002 01:28:46.562 - Recv: AT&FE1&C1&D2&K3V1W3S0=0<cr> 02-03-2002 01:28:46.562 - Command Echo 02-03-2002 01:28:46.562 - Recv: <cr><lf>OK<cr><lf> 02-03-2002 01:28:46.562 - Interpreted response: OK 02-03-2002 01:28:46.578 - Send: ATS7=60S30=0M0\N3%C3&K3B0N1X4<cr> 02-03-2002 01:28:46.578 - Recv: ATS7=60S30=0M0\N3%C3&K3B0N1X4<cr> 02-03-2002 01:28:46.578 - Command Echo 02-03-2002 01:28:46.578 - Recv: <cr><lf>OK<cr><lf> 02-03-2002 01:28:46.578 - Interpreted response: OK 02-03-2002 01:28:46.578 - Waiting for a call. 02-03-2002 01:28:46.593 - Send: at#cid=1<cr> 02-03-2002 01:28:46.593 - Recv: at#cid=1<cr> 02-03-2002 01:28:46.593 - Command Echo 02-03-2002 01:28:46.593 - Recv: <cr><lf>OK<cr><lf> 02-03-2002 01:28:46.593 - Interpreted response: OK 02-03-2002 01:28:46.609 - Send: ATS0=0<cr> 02-03-2002 01:28:46.609 - Recv: ATS0=0<cr> 02-03-2002 01:28:46.609 - Command Echo 02-03-2002 01:28:46.609 - Recv: <cr><lf>OK<cr><lf> 02-03-2002 01:28:46.609 - Interpreted response: OK 02-03-2002 01:29:27.812 - Recv: <cr><lf>RING<cr><lf> 02-03-2002 01:29:27.812 - Interpreted response: Ring     <<- here the UnimodemV driver recognizes the RING 02-03-2002 01:29:27.812 - TSP(0000): LINEEVENT: LINE_NEWCALL     <<- here the TSP recognizes the RING alert from the driver 02-03-2002 01:29:27.812 - TSP(0000): LINEEVENT: LINECALLSTATE_OFFERING 02-03-2002 01:29:27.812 - TSP(0000): LINEEVENT: LINEDEVSTATE_RINGING(0x1) 02-03-2002 01:29:29.062 - Recv: <cr> 02-03-2002 01:29:29.062 - Interpreted response: Informative 02-03-2002 01:29:29.062 - Recv: <lf> 02-03-2002 01:29:29.062 - Interpreted response: Informative 02-03-2002 01:29:29.062 - Recv: DATE = 0203<cr><lf><cr><lf>TIME = 0129<cr><lf><cr><lf>NM     <<-here is the 'verbose' CALLER ID response from the modem.  Since it DOES NOT MATCH the strings that the WINDOWS REGISTRY (and therefore, Unimodem) is expecting, because the .INF file set the REGISTRY improperly on installation of the driver, it is interpreted as UNKNOWN RESPONSE by Unimodem (see next line), and the data is not properly parsed or passed to the TSP 02-03-2002 01:29:29.062 - Unknown Response 02-03-2002 01:29:32.781 - Recv: <cr><lf>RING<cr><lf> 02-03-2002 01:29:32.781 - Interpreted response: Ring END WIN2000 MODEMLOG

 

Now look at the GOOD chat session between the Modem incoming CALLER ID string, the UNIMODEMV driver, and the TSP (TAPI Service Provider), after fixing the REGISTRY.    **This one includes an incoming and outgoing VOICEMAIL SESSION using TALKING CALLERID!!!

 

BEGIN WIN2000 MODEMLOG 02-04-2002 18:58:43.781 - File: C:\WINNT\System32\unimdm.tsp, Version 5.0.2175 - Retail 02-04-2002 18:58:43.781 - File: C:\WINNT\System32\unimdmat.dll, Version 5.0.2134 - Retail 02-04-2002 18:58:43.781 - File: C:\WINNT\System32\uniplat.dll, Version 5.0.2151 - Retail 02-04-2002 18:58:43.781 - File: C:\WINNT\System32\drivers\modem.sys, Version 5.0.2195 - Retail 02-04-2002 18:58:43.781 - File: C:\WINNT\System32\modemui.dll, Version 5.0.2146 - Retail 02-04-2002 18:58:43.781 - Modem type: HSP56 Generic MicroModem 02-04-2002 18:58:43.781 - Modem inf path: oem9.inf 02-04-2002 18:58:43.781 - Modem inf section: Modem5 02-04-2002 18:58:43.828 - 115200,8,N,1, ctsfl=1, rtsctl=2 02-04-2002 18:58:43.828 - Initializing modem. 02-04-2002 18:58:43.843 - Send: AT<cr> 02-04-2002 18:58:43.875 - Recv: AT<cr> 02-04-2002 18:58:43.875 - Command Echo 02-04-2002 18:58:43.875 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:58:43.875 - Interpreted response: OK 02-04-2002 18:58:43.890 - Send: AT&FE1&C1&D2&K3V1W3S0=0<cr> 02-04-2002 18:58:43.890 - Recv: AT&FE1&C1&D2&K3V1W3S0=0<cr> 02-04-2002 18:58:43.890 - Command Echo 02-04-2002 18:58:43.890 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:58:43.890 - Interpreted response: OK 02-04-2002 18:58:43.906 - Send: ATS7=60S30=0M1\N3%C3&K3B0N1X4<cr> 02-04-2002 18:58:43.906 - Recv: ATS7=60S30=0M1\N3%C3&K3B0N1X4<cr> 02-04-2002 18:58:43.906 - Command Echo 02-04-2002 18:58:43.906 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:58:43.906 - Interpreted response: OK 02-04-2002 18:58:43.906 - Waiting for a call. 02-04-2002 18:58:43.921 - Send: at#cid=1<cr> 02-04-2002 18:58:43.921 - Recv: at#cid=1<cr> 02-04-2002 18:58:43.921 - Command Echo 02-04-2002 18:58:43.921 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:58:43.921 - Interpreted response: OK 02-04-2002 18:58:43.937 - Send: ATS0=0<cr> 02-04-2002 18:58:43.937 - Recv: ATS0=0<cr> 02-04-2002 18:58:43.937 - Command Echo 02-04-2002 18:58:43.937 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:58:43.937 - Interpreted response: OK ** Here is the proper CHAT session between the Modem and the UnimodemV driver. Note that the CALLER ID response strings are now recognized and parsed, and the TSP (TAPI Service Provider) is properly sent the information: 02-04-2002 18:59:06.437 - Recv: <cr><lf>RING<cr><lf> 02-04-2002 18:59:06.437 - Interpreted response: Ring 02-04-2002 18:59:07.828 - Recv: <cr> 02-04-2002 18:59:07.828 - Interpreted response: Informative 02-04-2002 18:59:07.828 - Recv: <lf> 02-04-2002 18:59:07.828 - Interpreted response: Informative 02-04-2002 18:59:07.828 - Recv: DATE = 02-04-2002 18:59:07.828 - Interpreted response: DATE 02-04-2002 18:59:07.828 - Recv: 0204<cr><lf> 02-04-2002 18:59:07.828 - Recv: <cr> 02-04-2002 18:59:07.828 - Interpreted response: Informative 02-04-2002 18:59:07.828 - Recv: <lf> 02-04-2002 18:59:07.828 - Interpreted response: Informative 02-04-2002 18:59:07.828 - Recv: TIME = 02-04-2002 18:59:07.828 - Interpreted response: TIME 02-04-2002 18:59:07.828 - Recv: 1859<cr><lf> 02-04-2002 18:59:07.828 - Recv: <cr> 02-04-2002 18:59:07.828 - Interpreted response: Informative 02-04-2002 18:59:07.828 - Recv: <lf> 02-04-2002 18:59:07.828 - Interpreted response: Informative 02-04-2002 18:59:07.828 - Recv: NMBR = 02-04-2002 18:59:07.828 - Interpreted response: NMBR 02-04-2002 18:59:07.828 - Recv: 8005551212<cr><lf> 02-04-2002 18:59:07.828 - Recv: <cr> 02-04-2002 18:59:07.828 - Interpreted response: Informative 02-04-2002 18:59:07.828 - Recv: <lf> 02-04-2002 18:59:07.828 - Interpreted response: Informative 02-04-2002 18:59:07.828 - Recv: NAME = 02-04-2002 18:59:07.828 - Interpreted response: NAME 02-04-2002 18:59:07.828 - Recv: WILEY STACEY ST<cr><lf> 02-04-2002 18:59:12.437 - Recv: <cr><lf>RING<cr><lf> 02-04-2002 18:59:12.437 - Interpreted response: Ring 02-04-2002 18:59:12.437 - Answering the call. 02-04-2002 18:59:12.437 - 38400,8,N,1, ctsfl=1, rtsctl=1 02-04-2002 18:59:12.453 - Send: at#cls=8#ima=1<cr> 02-04-2002 18:59:12.453 - Recv: at#cls=8#ima=1<cr> 02-04-2002 18:59:12.453 - Command Echo 02-04-2002 18:59:12.453 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:12.453 - Interpreted response: OK 02-04-2002 18:59:12.468 - Send: at#vls=0<cr> 02-04-2002 18:59:12.468 - Recv: at#vls=0<cr> 02-04-2002 18:59:12.468 - Command Echo 02-04-2002 18:59:12.468 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:12.468 - Interpreted response: OK 02-04-2002 18:59:12.484 - Send: at#vbt=1<cr> 02-04-2002 18:59:12.484 - Received DLE Raw=116, Meaning is Handset Off Hook. 02-04-2002 18:59:12.484 - Recv: at#vbt=1<cr> 02-04-2002 18:59:12.484 - Command Echo 02-04-2002 18:59:12.484 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:12.484 - Interpreted response: OK 02-04-2002 18:59:12.500 - Send: ats30=60<cr> 02-04-2002 18:59:12.500 - Recv: ats30=60<cr> 02-04-2002 18:59:12.500 - Command Echo 02-04-2002 18:59:12.500 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:12.500 - Interpreted response: OK 02-04-2002 18:59:12.515 - Send: ata<cr> 02-04-2002 18:59:12.515 - Recv: ata<cr> 02-04-2002 18:59:12.515 - Command Echo 02-04-2002 18:59:17.406 - Recv: <cr> 02-04-2002 18:59:17.406 - Interpreted response: Informative 02-04-2002 18:59:17.406 - Recv: <lf> 02-04-2002 18:59:17.406 - Interpreted response: Informative 02-04-2002 18:59:17.406 - Recv: VCON 02-04-2002 18:59:17.406 - Interpreted response: OK 02-04-2002 18:59:17.484 - Setting wave format. 02-04-2002 18:59:17.500 - Send: at#vls=0<cr> 02-04-2002 18:59:17.500 - Recv: <cr> 02-04-2002 18:59:17.500 - Interpreted response: Informative 02-04-2002 18:59:17.500 - Recv: <lf> 02-04-2002 18:59:17.500 - Interpreted response: Informative 02-04-2002 18:59:17.500 - Recv: at#vls=0<cr> 02-04-2002 18:59:17.500 - Command Echo 02-04-2002 18:59:17.500 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:17.500 - Interpreted response: OK 02-04-2002 18:59:17.515 - Send: at#tl=7fff<cr> 02-04-2002 18:59:17.515 - Recv: at#tl=7fff<cr> 02-04-2002 18:59:17.515 - Command Echo 02-04-2002 18:59:17.515 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:17.515 - Interpreted response: OK 02-04-2002 18:59:17.515 - 38400,8,N,1, ctsfl=1, rtsctl=1 02-04-2002 18:59:17.515 - Starting wave play/record. 02-04-2002 18:59:17.531 - Send: at#vtx<cr> 02-04-2002 18:59:17.531 - Recv: at#vtx<cr> 02-04-2002 18:59:17.531 - Command Echo 02-04-2002 18:59:17.531 - Recv: <cr><lf>CONNECT<cr><lf> 02-04-2002 18:59:17.531 - Interpreted response: Connect 02-04-2002 18:59:21.750 - Ending wave play/record. 02-04-2002 18:59:21.750 - Send: <00><DLE><03> 02-04-2002 18:59:21.750 - Recv: <cr> 02-04-2002 18:59:21.750 - Interpreted response: Informative 02-04-2002 18:59:21.750 - Recv: <lf> 02-04-2002 18:59:21.750 - Interpreted response: Informative 02-04-2002 18:59:21.750 - Recv: VCON 02-04-2002 18:59:21.750 - Interpreted response: OK 02-04-2002 18:59:21.781 - Setting wave format. 02-04-2002 18:59:21.796 - Send: at#vls=0<cr> 02-04-2002 18:59:21.796 - Recv: <cr> 02-04-2002 18:59:21.796 - Interpreted response: Informative 02-04-2002 18:59:21.796 - Recv: <lf> 02-04-2002 18:59:21.796 - Interpreted response: Informative 02-04-2002 18:59:21.796 - Recv: at#vls=0<cr> 02-04-2002 18:59:21.796 - Command Echo 02-04-2002 18:59:21.796 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:21.796 - Interpreted response: OK 02-04-2002 18:59:21.812 - Send: at#tl=7fff<cr> 02-04-2002 18:59:21.812 - Recv: at#tl=7fff<cr> 02-04-2002 18:59:21.812 - Command Echo 02-04-2002 18:59:21.812 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:21.812 - Interpreted response: OK 02-04-2002 18:59:21.812 - 38400,8,N,1, ctsfl=1, rtsctl=1 02-04-2002 18:59:21.812 - Starting wave play/record. 02-04-2002 18:59:21.828 - Send: at#vtx<cr> 02-04-2002 18:59:21.828 - Recv: at#vtx<cr> 02-04-2002 18:59:21.828 - Command Echo 02-04-2002 18:59:21.828 - Recv: <cr><lf>CONNECT<cr><lf> 02-04-2002 18:59:21.828 - Interpreted response: Connect 02-04-2002 18:59:26.328 - Received DLE Raw= 49, Meaning is DTMF 1.     <<Here the caller pressed 1 to leave a message! THE REST OF THIS LOG IS IMPERTINENT, BUT YOU MAY BE INTERESTED IN THE FULL VOICEMAIL SESSION FROM THE UNIMODEM DRIVER VIEWPOINT. 02-04-2002 18:59:26.906 - Ending wave play/record. 02-04-2002 18:59:26.906 - Send: <00><DLE><18> 02-04-2002 18:59:26.906 - Recv: <cr> 02-04-2002 18:59:26.906 - Interpreted response: Informative 02-04-2002 18:59:26.906 - Recv: <lf> 02-04-2002 18:59:26.906 - Interpreted response: Informative 02-04-2002 18:59:26.906 - Recv: VCON 02-04-2002 18:59:26.906 - Interpreted response: OK 02-04-2002 18:59:26.953 - Setting wave format. 02-04-2002 18:59:26.968 - Send: at#vls=0<cr> 02-04-2002 18:59:26.968 - Recv: <cr> 02-04-2002 18:59:26.968 - Interpreted response: Informative 02-04-2002 18:59:26.968 - Recv: <lf> 02-04-2002 18:59:26.968 - Interpreted response: Informative 02-04-2002 18:59:26.968 - Recv: at#vls=0<cr> 02-04-2002 18:59:26.968 - Command Echo 02-04-2002 18:59:26.968 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:26.968 - Interpreted response: OK 02-04-2002 18:59:26.984 - Send: at#tl=7fff<cr> 02-04-2002 18:59:26.984 - Recv: at#tl=7fff<cr> 02-04-2002 18:59:26.984 - Command Echo 02-04-2002 18:59:26.984 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:26.984 - Interpreted response: OK 02-04-2002 18:59:26.984 - 38400,8,N,1, ctsfl=1, rtsctl=1 02-04-2002 18:59:26.984 - Starting wave play/record. 02-04-2002 18:59:27.000 - Send: at#vtx<cr> 02-04-2002 18:59:27.000 - Recv: at#vtx<cr> 02-04-2002 18:59:27.000 - Command Echo 02-04-2002 18:59:27.000 - Recv: <cr><lf>CONNECT<cr><lf> 02-04-2002 18:59:27.000 - Interpreted response: Connect 02-04-2002 18:59:31.484 - Ending wave play/record. 02-04-2002 18:59:31.484 - Send: <00><DLE><03> 02-04-2002 18:59:31.484 - Recv: <cr> 02-04-2002 18:59:31.484 - Interpreted response: Informative 02-04-2002 18:59:31.484 - Recv: <lf> 02-04-2002 18:59:31.484 - Interpreted response: Informative 02-04-2002 18:59:31.484 - Recv: VCON 02-04-2002 18:59:31.484 - Interpreted response: OK 02-04-2002 18:59:31.515 - Setting wave format. 02-04-2002 18:59:31.515 - 38400,8,N,1, ctsfl=1, rtsctl=1 02-04-2002 18:59:31.515 - Starting wave play/record. 02-04-2002 18:59:31.531 - Send: at#vrx<cr> 02-04-2002 18:59:31.531 - Recv: <cr> 02-04-2002 18:59:31.531 - Interpreted response: Informative 02-04-2002 18:59:31.531 - Recv: <lf> 02-04-2002 18:59:31.531 - Interpreted response: Informative 02-04-2002 18:59:31.531 - Recv: at#vrx<cr> 02-04-2002 18:59:31.531 - Command Echo 02-04-2002 18:59:31.531 - Recv: <cr><lf>CONNECT<cr><lf> 02-04-2002 18:59:31.531 - Interpreted response: Connect 02-04-2002 18:59:34.578 - Received DLE Raw= 49, Meaning is DTMF 1. 02-04-2002 18:59:34.578 - Ending wave play/record. 02-04-2002 18:59:34.578 - Send: <DLE>E 02-04-2002 18:59:34.578 - Received DLE Raw=  3, Meaning is End of Transmission(ETX). 02-04-2002 18:59:34.578 - Recv: <cr> 02-04-2002 18:59:34.578 - Interpreted response: Informative 02-04-2002 18:59:34.578 - Recv: <lf> 02-04-2002 18:59:34.578 - Interpreted response: Informative 02-04-2002 18:59:34.578 - Recv: VCON 02-04-2002 18:59:34.578 - Interpreted response: OK 02-04-2002 18:59:34.640 - Setting wave format. 02-04-2002 18:59:34.656 - Send: at#vls=0<cr> 02-04-2002 18:59:34.656 - Recv: <cr> 02-04-2002 18:59:34.656 - Interpreted response: Informative 02-04-2002 18:59:34.656 - Recv: <lf> 02-04-2002 18:59:34.656 - Interpreted response: Informative 02-04-2002 18:59:34.656 - Recv: Ea 02-04-2002 18:59:34.656 - Unknown Response 02-04-2002 18:59:34.656 - Recv: t#vls=0<cr> 02-04-2002 18:59:34.656 - Unknown Response 02-04-2002 18:59:34.656 - Recv: <cr> 02-04-2002 18:59:34.656 - Unknown Response 02-04-2002 18:59:34.656 - Recv: <lf>OK<cr><lf> 02-04-2002 18:59:34.656 - Unknown Response 02-04-2002 18:59:34.968 - Setting wave format. 02-04-2002 18:59:34.984 - Send: at#vls=0<cr> 02-04-2002 18:59:34.984 - Recv: at#vls=0<cr> 02-04-2002 18:59:34.984 - Command Echo 02-04-2002 18:59:34.984 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:34.984 - Interpreted response: OK 02-04-2002 18:59:35.000 - Send: at#tl=7fff<cr> 02-04-2002 18:59:35.000 - Recv: at#tl=7fff<cr> 02-04-2002 18:59:35.000 - Command Echo 02-04-2002 18:59:35.000 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:35.000 - Interpreted response: OK 02-04-2002 18:59:35.000 - 38400,8,N,1, ctsfl=1, rtsctl=1 02-04-2002 18:59:35.000 - Starting wave play/record. 02-04-2002 18:59:35.015 - Send: at#vtx<cr> 02-04-2002 18:59:35.015 - Recv: at#vtx<cr> 02-04-2002 18:59:35.015 - Command Echo 02-04-2002 18:59:35.015 - Recv: <cr><lf>CONNECT<cr><lf> 02-04-2002 18:59:35.015 - Interpreted response: Connect 02-04-2002 18:59:36.125 - Ending wave play/record. 02-04-2002 18:59:36.125 - Send: <00><DLE><03> 02-04-2002 18:59:36.125 - Recv: <cr> 02-04-2002 18:59:36.125 - Interpreted response: Informative 02-04-2002 18:59:36.125 - Recv: <lf> 02-04-2002 18:59:36.125 - Interpreted response: Informative 02-04-2002 18:59:36.125 - Recv: VCON 02-04-2002 18:59:36.125 - Interpreted response: OK 02-04-2002 18:59:36.125 - Hanging up the modem. 02-04-2002 18:59:36.140 - Send: ATH<cr> 02-04-2002 18:59:36.140 - Recv: <cr> 02-04-2002 18:59:36.140 - Interpreted response: Informative 02-04-2002 18:59:36.140 - Recv: <lf> 02-04-2002 18:59:36.140 - Interpreted response: Informative 02-04-2002 18:59:36.140 - Recv: ATH<cr> 02-04-2002 18:59:36.140 - Command Echo 02-04-2002 18:59:36.140 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:36.140 - Interpreted response: OK 02-04-2002 18:59:36.140 - 115200,8,N,1, ctsfl=1, rtsctl=2 02-04-2002 18:59:36.140 - Initializing modem. 02-04-2002 18:59:36.156 - Send: AT<cr> 02-04-2002 18:59:36.156 - Recv: AT<cr> 02-04-2002 18:59:36.156 - Command Echo 02-04-2002 18:59:36.156 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:36.156 - Interpreted response: OK 02-04-2002 18:59:36.171 - Send: AT&FE1&C1&D2&K3V1W3S0=0<cr> 02-04-2002 18:59:36.171 - Recv: AT&FE1&C1&D2&K3V1W3S0=0<cr> 02-04-2002 18:59:36.171 - Command Echo 02-04-2002 18:59:36.171 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:36.171 - Interpreted response: OK 02-04-2002 18:59:36.187 - Send: ATS7=60S30=0M1\N3%C3&K3B0N1X4<cr> 02-04-2002 18:59:36.187 - Recv: ATS7=60S30=0M1\N3%C3&K3B0N1X4<cr> 02-04-2002 18:59:36.187 - Command Echo 02-04-2002 18:59:36.187 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:36.187 - Interpreted response: OK 02-04-2002 18:59:36.187 - Waiting for a call. 02-04-2002 18:59:36.203 - Send: at#cid=1<cr> 02-04-2002 18:59:36.203 - Recv: at#cid=1<cr> 02-04-2002 18:59:36.203 - Command Echo 02-04-2002 18:59:36.203 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:36.203 - Interpreted response: OK 02-04-2002 18:59:36.218 - Send: ATS0=0<cr> 02-04-2002 18:59:36.218 - Recv: ATS0=0<cr> 02-04-2002 18:59:36.218 - Command Echo 02-04-2002 18:59:36.218 - Recv: <cr><lf>OK<cr><lf> 02-04-2002 18:59:36.218 - Interpreted response: OK 02-04-2002 19:37:17.734 - Session Statistics: 02-04-2002 19:37:17.734 -                Reads : 103 bytes 02-04-2002 19:37:17.734 -                Writes: 73 bytes END WIN2000 MODEMLOG

 

3. DRIVER DOWNLOAD - After MUCH experimentation with the many PC Tel drivers offered everywhere online, THIS is the driver which I have found is the STARTING POINT for the PCTel HSP on WINDOWS 2000:   PCI_800_0026 WinXP 2/2/2002 - Note: the above driver is probably the best driver to use at this time for Windows 2000, Windows XP and Windows ME. IMPORTANT NOTE! The Mdmchipv.inf file included in the above archive needs a VERY SLIGHT alteration BEFORE it is installed by Windows.   HOW TO MODIFY THE Mdmchipv.inf FILE 1. Unzip the archive into a temporary directory 2. Open the Mdmchipv.inf file with a text editor. 3. Add the following lines to the [MfgAddReg] section of the .INF file       HKR, Responses, "DATE = ", 1, 93, 00, 00,00,00,00, 00,00,00,00       HKR, Responses, "TIME = ", 1, 94, 00, 00,00,00,00, 00,00,00,00       HKR, Responses, "NMBR = ", 1, 95, 00, 00,00,00,00, 00,00,00,00       HKR, Responses, "NAME = ", 1, 96, 00, 00,00,00,00, 00,00,00,00       HKR, Responses, "MESG = ", 1, 97, 00, 00,00,00,00, 00,00,00,00 4. Save the Mdmchipv.inf file **Here is a copy of the driver with the .INF file already modified. PCI_800_0026 WinXP.zip 4. HOW TO INSTALL THE NEW DRIVER 1. Use the ADD/REMOVE HARDWARE applet in the WINDOWS CONTROL PANEL to REMOVE the PCTel Modem from the system. This applet may also be referred to as SYSTEM SETTINGS or DEVICE MANAGER. 2. Click HERE to find the PCTEL OEM .INF files on your system (this file is SAFE to RUN) 3. Follow the instructions given in the output report and DELETE the .INF and .PNF files which contained PCTel data from your operating System INF directory. This insures that the modem drivers are COMPLETELY removed. 4. Restart the system. 5. When WINDOWS restarts and prompts you to install drivers for the newly detected hardware, BE SURE AND BROWSE TO THE LOCATION OF THE NEW DRIVER YOU JUST OBTAINED! **IMPORTANT NOTE** If WINDOWS tells you it has found a better driver, IGNORE that, and ONLY INSTALL THE DRIVER YOU JUST OBTAINED AND MODIFIED. 6. WINDOWS will install the Modem drivers, and the TAPI Voice drivers for the modem! IMPORTANT NOTE When you visit the MICROSOFT PRODUCT UPDATE Website, they will try and give you a NEW PCTel driver. DO NOT DOWNLOAD THAT DRIVER !! REFERENCES MSDN .INF Overview MSDN TAPI Overview MSDN TSPI Info MSDN TAPI 3.1 Info MSDN Unimodem Overview MSDN Unimodem 'Responses' Info

Here is some more useful information to digest.

In a nutshell, yes almost anyone with this problem can resolve it.

Those numbers are the DATA STRUCTURE for the response that Unimodem uses.
Using a developer tool from Microsoft called 'PROCALC' the numbers are
derived for the verbose data string you get from the modem.  Unimodem
processes this along with the TSP to know what is coming from the modem and
when to parse for data, event handle, etc.  See this reference page:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/modem/hh/mo
dem/modemref1_90vm.asp

Every modem response string has a corresponding data structure, that means
more to TAPI than the verbose string comiong from the modem, as you may
imagine. Especially since the verbose strings vary from modem to modem - ***
THIS IS IN FACT THE WHOLE REASON FOR THE UNIMODEM DRIVER IN THE FIRST
PLACE - UNI-MODEM (one modem driver) - amazing concept - in theory.  We find
out now how LAZY developers leave good theory in the garbage with poor
execution (no offense to you).

Look at this .INF entry - a modem response string & data structure:

HKR,Responses,"<cr><lf>CONNECT 28800/PROTOCOL: ALT/COMPRESSION: CLASS
5<cr><lf>",1,02,03,80,70,00,00,00,00,00,00

There are a BUNCh of these in the .INF file, one for EVERY POSSIBLE connect
type, with compression, without, with error correction, without, for every
speed.  It is a long section...

These are UNIMODEM registry entries which basically parse the verbose
response from the modem, WHATEVER IT IS, even if it said 'Hey Moe' - then
PASSES a data struture that TAPI can decode and know EXACTLY what the
verbose string means...

The binary data structure foloowing the verbose string in each line
corresponds to the following C structure:

typedef struct MSS {
BYTE  bResponseState;
BYTE  bNegotiatedOptions;
DWORD dwNegotiatedDCERate;
DWORD dwNegotiatedDTERate;
};


***THE GOOD NEWS*** None of this develeoper junk matters, because IT IS THE
SAME DATA STRING FOR EVERY MODEM :-)  Well err, the numbers anyway.   The
actual ASCII STRING may be SLIGHTLY different from modem to modem or phone
company to phone company, *** and this too IS CAUSING MANY PROBLEMS FOR
PEOPLE!!!

For example, many people SHOULD NOT HAVE THE SPACE between "DATE ="

Instead, many people are given this string by their modem when caller ID is
passed to it:  "DATE= 0205" - notice no space between DATE and EQUAL SIGN.
YET IF THE INCOMING STRING DOES NOT MATCH EXACTLY WHAT THE UNIMODEM DRIVER
EXPECTS, IT WILL NOT PARSE !!  This SIMPLE syntax problem will also blow it
for many people.

In fact, it is safe to go ahead and add all variants to the .INF file before
installing the driver, like this:
      HKR, Responses, "DATE = ", 1,93,00,00,00,00,00,00,00,00,00
      HKR, Responses, "TIME = ", 1,94,00,00,00,00,00,00,00,00,00
      HKR, Responses, "NMBR = ", 1,95,00,00,00,00,00,00,00,00,00
      HKR, Responses, "NAME = ", 1,96,00,00,00,00,00,00,00,00,00
      HKR, Responses, "DATE = ", 1,93,00,00,00,00,00,00,00,00,00
      HKR, Responses, "TIME= ", 1,94,00,00,00,00,00,00,00,00,00
      HKR, Responses, "NMBR= ", 1,95,00,00,00,00,00,00,00,00,00
      HKR, Responses, "NAME= ", 1, 96,00,00,00,00,00,00,00,00,00
      HKR, Responses, "MESG= ", 1, 97,00,00,00,00,00,00,00,00,00
      HKR, Responses, "MESG= ", 1,97,00,00,00,00,00,00,00,00,00

*** Now, also, some people may NOT HAVE <cr> (carriage return) and <lf>
(line feed) set up as 'Informational' in their Unimodem responses.  This
means, that they need to also add them to the .INF file, like this:

HKR, Responses, "<cr>", 1, 01, 00, 00,00,00,00, 00,00,00,00
;00
HKR, Responses, "<lf>", 1, 01, 00, 00,00,00,00, 00,00,00,00
;00

Otherwise, the LEADING AND TRAILING <cr><lf> before the each of the four
CALLER ID STRINGS COMING IN (DATE = 0205 for example) will again NOT MATCH
the string in the registry! (go back and look at my 'bad session' log file)

The modem only gets FOUR strings from the phone company for caller id.
USUALLY (again, a geographic variable) they are:

NMBR (the phone number)
NAME (the name)
DATE (the date)
TIME (the time)

The data following these strings needs to be parsed properly and, THAT IS
ALL :-)

HOWEVER, some people may get strings like this from the phoneco:
NMR (the phone number)
NME (name)

etc etc,  you can see that AGAIN, these must be DETERMINED (using
Hyperterminal or preferably the modem log) AND THEN APPROPRIATELY ENTERED IN
THE .INF FILE BEFORE THE DRIVER IS INSTALLED!!

It all comes down to starting a modem log, and then viewing it after a
session to see what EXACTLY the syntax of the CALLER ID strings are for your
modem/phone service, and then simply mod the driver .INF to match them !

It is easy to start a modem log - in fact most installations of WindowsNT do
it automatically.  The log can be found in the \WINNT directory, named
"modemlogxxxxxxx.txt" where xxxxx is the common name of the modem driver.
If it is not logging, use the DIAGNOSTICS tab on the MODEM PROPERTIES SHEET
accessed by DEVICE MANAGER.

also - re: caller id - it actually ALL starts with a BINARY STRING which is
sent down the phone line....

the modem decodes this, and as you may expect, they do it differently.  Some
may or may not put <cr> and <lf> between each of the 4 values...

so fine tuning the expected strings in the .INF file and reinstalling the
driver is crucial.

See this doc for how it all gets started, and what makes TalkingCallerID do
it's thing:
http://www.howstuffworks.com/question409.htm

OK, another thing about the registry.  The placement of these strings in the
.INF file is important.

HERE IS YET ANOTHER THING I HAVE FOUND!!!  Causing many people problems, I
am sure.

EVEN IF someone has the proper .INF entries, often I have found them in the
WRONG [heading]!!


Apparently many people are still placing thes ein a place where they do some
good for WIN95/98

But the WinNT5 Unimodem driver wants these strings to be IN THE SAME KEY as
the CONNECT/BUSY/RING etc strings!!!

many inf files are not placing them there - simply moving them or copying
them to the proper key gets things going!!!

OK - here's a summary analogy of UNIMODEM/TAPI:

The ENTRIES in the UNIMODEM KEY in the REGISTRY are NOTHING MORE THAN
TRANSLATIONS from verbose to data.  'This' means 'That' - that is all the
entries tell the OS.

In this case:
HKR, Responses,"DATE = ",1,93,00,00,00,00,00,00,00,00,00

you are saying "the Verbose response string 'DATE = ' corresponds to TAPI
message '1,93,00,00,00,00,00,00,00,00,00', which tells TAPI that the data is
CALLER ID DATE data.

You could just as easily do this:
HKR, Responses,"HEY NORM = ",1,93,00,00,00,00,00,00,00,00,00

and  WHENEVER the string 'HEY NORM = ' is detected, TAPI will assume it is
CALLER ID DATE data and parse the following data!

I did add VCON to my registry, in the KEY where all the 'CONNECT' responses
are found.  It is found more often in the .INF files put out by the modem
mfgs, than the caller ID strings, but still perhaps not in the correct key
[heading] for WinNT5.  It was the only other command I added.   As
indicated, perhaps a <cr> and <lf> may be needed for some folks if they have
been left out of the .INF as 'Informational' responses.

As an example, each CALLER ID STRING actually comes in with <cr><lf>
preeceeding and trailing (for me anyhow).  Example:   <cr><lf>DATE =
0203<cr><lf>

**BUT I HAVE FOUND THIS** - Some modem .INF files will put THESE responses
in the KEY:

HKR, Responses,"<cr><lf>DATE = ",1,93,00,00,00,00,00,00,00,00,00
HKR, Responses,"<cr><lf>TIME = ",1,94,00,00,00,00,00,00,00,00,00
HKR, Responses,"<cr><lf>NMBR = ",1,95,00,00,00,00,00,00,00,00,00
HKR, Responses,"<cr><lf>NAME = ",1,96,00,00,00,00,00,00,00,00,00
HKR, Responses,"<cr><lf>MESG = ",1,97,00,00,00,00,00,00,00,00,00

notice the <cr><lf> is added in the REGISTRY as part of the expected
response along with the verbose word, ie DATE.  **BUT**  I feel that making
<cr> and <lf> as STANDALONE 'Informational' RESPONSES only, like I
previsouly mentioned and exampled on another email, leaves more room for the
variables in the different modems/drivers/phone cos.  Each <cr>  and <lf>
is just individually parsed and stripped, leaving the real variable which is
needed to be easily found by Unimodem when parsing the modem I/O.

If you look at my LOG files, you can really see this.  If I had used KEYS
like those listed above, I may have had other problems and had to do further
tweaking or add combinations of response keys with varying uses of <lf> and
<cr> as required preceeding,  I think it is much easier this way having
<cr> and <lf> as seperate keys in the REG.

OK, I added  VCON to the .INF file, so it got placed in the registry by the
'new hardware' installer.  It could probably go into the same key with all
the other CONNECT responses, but I placed it in a different key.

HKR, Responses, "VCON", 1, 00, 00, 00,00,00,00, 00,00,00,00

Here is the .INF section, which seemed to missing from many PCTel .INF
files, and all seems to be related to voice.  I guess I misspoke about just
adding 'VCON' to the REG to get voice working, obviously all of this, or
most of it, is probably required.

Note I also have the 'CALLER ID REPSONSE' keys in THIS section, AS WELL AS
the [mfgadd] section, for good measure.


[PCTEL_VOICE_ALL]   ; PCtel baseline voice settings
HKR,,Enumerator,,serwave.vxd
HKR,, VoiceManufacturerID,  1, 01,00
HKR,, VoiceProductIDWaveIn, 1, 80,00
HKR,, VoiceProductIDWaveOut,1, 81,00
HKR,, VoiceProductIDHandsetWaveIn,1, 82,00
HKR,, VoiceProductIDHandsetWaveOut,1, 83,00
HKR,, VoiceMixerMid,          1,02,00
HKR,, VoiceMixerPid,          1,99,01
HKR,, VoiceMixerLineID,       1,00,00,05,00

HKR, EnableCallerID, 1,, "at#cid=1<cr>"
HKR, DisableCallerID, 1,, "at#cid=0<cr>"
HKR,, CallerIDPrivate,, "P"
HKR,, CallerIDOutSide,, "O"
HKR,, VariableTerminator,,<cr><lf>
HKR, GenerateDigit,           1,, "at#vts=<Digit><cr>"

HKR, Responses, "VCON", 1, 00, 00, 00,00,00,00, 00,00,00,00
HKR, Responses, "DATE = ", 1, 93, 00, 00,00,00,00, 00,00,00,00
HKR, Responses, "TIME = ", 1, 94, 00, 00,00,00,00, 00,00,00,00
HKR, Responses, "NMBR = ", 1, 95, 00, 00,00,00,00, 00,00,00,00
HKR, Responses, "NAME = ", 1, 96, 00, 00,00,00,00, 00,00,00,00
HKR, Responses, "MESG = ", 1, 97, 00, 00,00,00,00, 00,00,00,00

[PCTEL_VOICE_SERWAVE]   ; PCtel serial wave settings
HKR,, VoiceProfile,                     1, 21,10,01,02
HKR,, HandsetCloseDelay,                1, 8,00,00,00
HKR, StartPlay,                         1,, "at#vtx<cr>"
HKR, StopPlay,                          1,, "None"
HKR, StopPlay,                          2,, "NoResponse"
HKR, StartRecord,                       1,, "at#vrx<cr>"
HKR, StopRecord,                        1,, "None"
HKR, StopRecord,                        2,, "NoResponse"
HKR,, TerminateRecord,,                 "<h10>E"
HKR,, TerminatePlay,,                   "<h10><h03>"
HKR,, AbortPlay,,                       "<h10><h18>"
HKR, LineSetPlayFormat,                 1,, "at#vls=0<cr>"
HKR, LineSetPlayFormat,                 2,, "at#tl=7fff<cr>"
HKR, LineSetRecordFormat,               1,, "None"
HKR, LineSetRecordFormat,               2,, "NoResponse"
HKR, VoiceToDataAnswer,                 1,, "at#ima=0#cls=0<cr>"
HKR, VoiceToDataAnswer,                 2,, "ata<cr>"
HKR, VoiceAnswer,                       1,, "at#cls=8#ima=1<cr>"
HKR, VoiceAnswer,                       2,, "at#vls=0<cr>"
HKR, VoiceAnswer,                       3,, "at#vbt=1<cr>"
HKR, VoiceAnswer,                       4,, "ats30=60<cr>"
HKR, VoiceAnswer,                       5,, "ata<cr>"
HKR, VoiceDialNumberSetup,              1,, "at#cls=8#ima=1<cr>"
HKR, VoiceDialNumberSetup,              2,, "at#vls=0<cr>"
HKR, VoiceDialNumberSetup,              3,, "at#vrn=0<cr>"
HKR, VoiceDialNumberSetup,              4,, "at#vbt=1<cr>"
HKR, VoiceDialNumberSetup,              5,, "ats30=60<cr>"

HKR, WaveDriver, XformModule,  , "umdmxfrm.dll"
HKR, WaveDriver, XformID,     1, 04, 00
HKR, WaveDriver, BaudRate,    1, 00, c2, 01, 00
HKR, WaveDriver, WaveDevices, 1, 02, 00
HKR, WaveDriver, WaveHardwareID, , "FullDuplex"

The following concerns distinctive ringing:

First off, there is a string which many TAPI apps look to use to ENABLE
Distict Ring:

HKR, EnableDistinctiveRing, 1,, "at-sdr=7<cr>"

Also: The Distinctive Ring information that the modem returns is variable in
length. Therefore, string termination characters must be specified. For
example, the .inf file contains the following entry:

HKR,, VariableTerminator,,<cr><lf>    <<-- again it's our two friends
<cr> and <lf>, this time definfed together as a terminator string.

See the table below.

All you have to do is match the VERBOSE string the modem is getting for the
distinctive ring, with the matching RESPONSE STATE string, (the numbers),
and BINGO, it should fly.

Again, starting a modem log should help a great deal.  You can see the exact
VERBOSE messages the modem is receiving, and make a line in the .INF file or
REG, to deal with it.

My phone co does not support distinctive ring, so I have NO idea what the
VERBAL MESSAE looks like form the modem that indicates it, but I do know
that if you match it up with the proper response state, TAPI will be happy!
(hey, I ryhmed)

LOOK AT THIS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q272943
Microsoft basically tells you they screwed up, and to go get another driver!
"CAUSE
This problem occurs because the Windows 2000 implementation of UNIMODEM in
TAPI does not support the distinctive ring feature. 

Referring to the table below, it appears that TWO variables define the distinct ring, the RING DURATION and
the RING BREAK.   This is how the modem can tell the ring is DISTINCT from
the normal ring.   This is called 'CADENCE' in phone co. vernacular, I
believe.

**ALSO** adding the proper DISTINCT RING lines to the .INF file will ENABLE
A TAB ON THE MODEMS PROEPRTY SHEET UNDER CONTROL PANEL, CALLED DISTINCT
RING!   If that tab is not there, someone dosn't have the right REG key
entry, or doesn't have one at all :-)

Happy ringing!

Additional Voice responses include:

Return to Home Page