dmitry

How can I initiate a process (application, sql trigger, windows event, etc) when a call comes in?

I'm using the SMDR output from DeltaServer, and supposed I could build an application with a timer that watches the csv file, but that seems like such a hack!

Thanks in advance...

big70

Wat do you want to trigger?? (a program,lights,alarm)
If you need a no/nc you have relais that are triggerd bij the voltage of a pot.
:D

Greets Peter

PBXtech.info

 

dmitry

I'm looking to integrate the phone system with the CRM I'm building.

For example, if there was a way to get DeltaServer log every incoming call in to a SqlServer database (which I believe there is a way to do but I have not been able to find), I could then have the incoming call trigger an application on the receipients desk that would come up with the customers history.

mallgood

I think your first idea would be the easiest, even though is seems hackish.
The way I would think about doing it is setting up Delta Server to log to a file. Then write a custom parsing application that would watch for new data on that file (a loop until it doesn't get an EOF). Then parse the new information into the SQL database. Would work quite slick I would think. Shouldn't be that hard at all. Especially with the new .net stuff, which has all kind of SQL/DB stuff integrated right in. Not to mention, if you run delta server, you are going to be running the .net platform anyways (DS is a .net application)
The only problem I could forsee is if there are tons of calls coming in at once. Then the parser app might take a minute to catch up.

The other really good thing about this solution is.. you don't need to pay more $$$ to Avaya for licenses, etc... :D

Cephas

Purchase Phone Manager PRO licences for anyone who needs these screen pops. In the configuration options for PMPro, in the screen pop settings, you can launch any third party application with command line parameters indicating the callerID, etc.


Peter

corhavelaar

Using SMDR for the function you mention is not an option. SMDR information will only be available after disconnecting the call.
I suggest to use the free Tapi driver for each user.
Write your software in a Server/client way and let the client software communicate with the Tapi driver were the information you need is available and then collect data from the server to display on the screen of the client.
I've done this before and is not that hard to do, programming in VB is more difficult with TAPI as with C++ or C#.
Also you can purchase a TAPI Link Pro license and let the server do all communication with the IP Office.

I've added a sample VB Tapi project i found on the web and found it usefull for me, maybe it will help you out.
Good Luck

Attached Files

Een.zip (63.6 KB, 22 views)

PBXtech.info

 

dmitry

The newer version of Delta Server (5.0) has an SMDR Port configuration. How can I use this?

corhavelaar

SMDR info comes always after call completion so it is no use for screen popping.

corhavelaar

Hi dmitry,

I have been digging in some old info ( Network Alchemy ) and found the following wich will be very usefull for you, its free and it still works ( tested on SOE 3.0.67 ) :

Connect your PC to the DTE port of the IP Office, 38400,8,N,1.
Start Hyperterminal with the above settings and type AT, the unit response with OK.
Then type AT%CCID=5.
pickup a handset and start dialling a number you will get output like this:
CALL: 5.1.1 State=0 Cut=1 Music=0.0 Aend="Line 5" (2.1) Bend="" [] (0.0) CalledNum=123456789 ()CallingNum=0987654321 () Internal=0 Time=0 AState=0
This will be presented as soon as the call comes in.

All events invoked by any extension or line will be shown here.

corhavelaar

Addendum..

These setings will not survive a reboot.

if that is needed then crate a user named "DTEDefault", no extensionnumber or anything and put the following as a trustednumber "AT%CCID=5".

Then it will survive a reboot.

dmitry

Awesome - thanks!

AllanR

I've tried this two ways; a .NET service that monitors the Delta output using a class derived from FileSystemWatcher, and a Win32 service that uses the DevLink API. The first way works good (no latency even at high call volumes - although we do have serious backend kit), but the second is definately cleaner/more elegant from a software perspective. If you email me (allan.rogers@prostate-cancer.org.uk), I will give you as much info as I can. I will even give you some of my code.. no guarantees!