TAPI 3.x sample source code?

[o.mascia]

Hello,

Is there any sample code, even pseudo-code, about how to correctly establish calls, and be notified of incoming calls through the '3CX TAPI Service Provider' exposed when the 3CX Assistant (v9) has been installed?

Following the obvious way of doing things through TAPI 3, I can establish outgoing calls from my application over the deskphone whose Assistant is configured for (MakeCall and then Connect). These calls always set themselves up as if the 'Use intercom when calling' is NOT checked in Assistant, wether it is checked or not in the assistant. This means my deskphone first rings to notify me of the "MakeCall", I answer, get to listen to the on-hold music while the outgoing call is actually setup and ringing on the destination (external or extension) and then when the party answer, the on-hold music stops and I'm in conversation.

A) I'd like to be able (if at all possible) to setup these calls just as when the 'Use intercom when calling' is checked : my deskphone rings while the call is already being setup to my recipient, if I answer I hear the ringing tone just as if I had dialed manually.

B) Following and adapting typical Microsoft samples, I somehow do not seem to be able to capture any notification for incoming calls. Is it supported at all by the '3CX TAPI Service Provider' exposed / installed by Assistant V9?

C) What about these TAPI interfaces when V10 will be released (with a web-based Assistant) ? Is 3CX committed to continue providing those TAPI interfaces?

Thanks in advance for any pointers or clarifications.
I have a commercial license to 3CX v9.

 

[FlightRisk]

Hi,

First, let me suggest that TAPI 3 might not be the best version for working with a PBX. TAPI 3 is not the next version of TAPI 2, so it is unfortunate they gave it that version number instead of giving it a different product name. TAPI 3 is a COM interface for TAPI 2 with less features, other than adding a different way to handle media streaming. It is easy to write simple applications at the expense of cutting out some features.

You might want to take a look at our tools here http://www.exceletel.com. There are lots of samples in the support section. We also have some new controls that are easier to use than the controls you see. We have a caller ID control a call control, even a transfer and conference control. We implement virtually the entire lower-level TAPI 2.2 specification.

Many PBXs ring the local desk phone because their TSP is written in attended mode instead of automated mode. They assume that you don't want to create a dial reminder system, but that you want to interact with the phone to dial from a CRM system. In that scenario, it makes no sense to connect a call without you picking up a handset. How they implement things like this is completely up to them and hopefully with many folks asking for features, they will improve the TSP.

I have recently started testing the TSP in more detail and it looks like there are quite a few bugs and some misinterpretations of the TAPI specification. I've seen this happen quite a bit, even with larger companies. The market for people wanting to control the PBX via software is smaller than the market that wants a PBX and some desk phones. They don't get as much input from customers about what may or may not be broken. And often, because they don't have a lot of expertise in it, they try to steer customers in another direction, especially if they have their own API they charge for. TAPI itself is often misunderstood and since we aren't back in the early 90s anymore when TAPI was new and we were having "bake offs" to clarify the documentation and tweak features, it can be hard to get information for a vendor to know exactly how a feature is supposed to be implemented.

What you are trying to do is fairly easy. We help dozens of people a month do inbound caller id screen pops and outbound dialing from a database. With our tools, there is almost no code to write since in most cases, you just take one of our sample programs and drop it into your other code and it works. We also have a TeleScope test utility that comes with TeleTools, so it allows you to learn, debug, prototype, test your device. and log everything that is happening. Happy to help if I can.

Fred
http://www.exceletel.com
"Answering your call for telephony development"
TAPI and SIP consulting and components

 

[o.mascia]

Thanks Fred, I'll have a look to and evaluate those tools.
I hope though that 3CX will have some words about concerns of my C) point.

 

[o.mascia]

Redoing the work with TAPI 2.2 helped clarify a couple things. Thanks for the advice. I could even redo it correctly with TAPI 3, without real issues except one (see end of this post).

Going back to my initial questions, A) is not possible unless the TAPI provider glue between Assistant and Windows TAPI server is reworked, offering additional configuration facilities. That is not real issue, I can do with how these calls are setup after all.

B) Works well, but after some time, applications stop receiving TAPI events. When that happens, the only cure seems to reboot. I suppose it should be possible to clear things up, restarting 3cxassistant and tapisrv (and what-else?), but couldn't yet find the magical recipe. If my test application has to be terminated from debugger, instability comes up quickly. When all resources are managed correctly, it looks like it works much longer, but I still have to see it succeed for a full day though.

C) I have no idea of what is in the works regarding the 3CX TAPI Service Provider in the context of the v10 Assistant, but I hope that won't be abandoned, it would be a step backward. Out of the box interfaces to Outlook is great for whoever needs it and useless for those who don't care and don't use Outlook.