Open a web page when I receive an incoming call

It depends a lot on the PBX in use - I've work with Avaya and CallMedia servers. Both of those companies provided a small desktop client and a DLL which can be referenced from within code.

The biggest problem is informing the web page once the system tray app gets an event. Launching a browser can be slow and is not a good user experience for call handling. Better is to keep a browser open and receive events..

The company I worked for used some pretty out-dated tech so they had:

PBX --(XML)-- PBX System Tray Client --(COM)-- Our own desktop app --(COM)-- An ActiveXControl embedded in the page --(Javascript)-- The website framework which handled the event as appropriate

As you can see it was quite long and convoluted - A more elegant approach would be to have a silverlight/similar app embedded on the page which receives events from the system tray client (via a web service or similar?)

You also need to address the question of a) multiple pages open - do all get the events? and b) swapping PBX at a later date shouldn't require a complete re-write.

As I left that company we were implementing a mechanism where our app received messages from the PBX directly via XML. Silverlight controls on any/all web pages registered with our desktop app via 2-Way WCF. We then had our desktop app send the appropriate events to the appropriate page.

Some other things to consider: Are you going to be handling mixed-channel? ie can handling an email block an incoming call event? If so, you need some sort of 2-way comms to say "Rejecting call...". You also need to be careful about what State the agents' telset is in - If you go to an "available" state before you finish saving data, you can potentially browse away before recording everything. Also, in my experience, agents are really happy to press the buttons on the telset rather than in your app - so you need to handle unexpected status changes.

Also consider transferring calls - most modern PBX allow a call transfer to occur in such a way that an id is associated with the call - so if it's an internal transfer, the recipients' screen can show all call notes/etc.

I can provide more info if you can clarify what PBX/etc. you're using and what events you need to handle

Events I'd recommend you handle at a minimum: Call ringing, Call answered, Call Dropped, Call Transferred

and you should be able to raise: Accept Call, Place Call, Drop Call, Transfer Call (Hot and Cold transfers, optionally with data if it's internal)

Of course this may be overkill for your solution :)

Edit: I forgot to add that our solution also handled logging the agents on/off of the telset when they logged into the web app - This gave a really nice user experience but required handling all the logon/logoff variables as well as maintaining a lookup table of user->extension #

Thanks for that answer. The problem is that we want to support our clients PBX systems, whatever they happen to be. Perhaps a better way to do this is to ask "Which phone systems provide an app that can open a web page when a call is received?"

rjmunro 2010-08-13 14:16:35

As far as I'm aware, there is not a consistent cross-PBX way to achieve that. Many systems don't pass TAPI/TSAPI messages to the client PC (some don't even pass to client telset using their own internal mechanism). As such there are no generic events to intercept.You also need to ask what happens if the client uses Skype/Software VOIP.If you find an answer, I'd be interested to know how you did it but I think you'll be facing a very convoluted solution if you can get any to work.

Basiclife 2010-08-13 14:25:14

Of course, you COULD write a generic system tray app that can handle multiple PBXs and add support for each enw PBX in a modular way - you'd then get a standardised set of events in your app and you can start small and expand as required.Another problem with your approach is handling events which don't match a common interface - So some PBXs will send a "Call Delivered", others will send a "Call Offered", etc... Some include caller Id, some also have IVR/Time in queue information embedded. You could probably pull out the data you want but again it may be messy

Basiclife 2010-08-13 14:27:20

I'm just surprised that a generic system tray app, or lots of different ones for different PBXs don't exist already. NCID seems to be a framework for such a system, but seems to be aimed at home users who have an old modem they can use as a Caller ID -> serial adaptor. It also requires a linux server.

rjmunro 2010-08-13 16:30:14

I can't say for certain it doesn't exist, merely that I haven't come across one - I've been writing software for call centres and the like for years but as you can probably tell from my answer, we use quite complex integration.I think the problem basically boils down to the fact that comms between the PBX and client PC are non-standard. Each supplier has their own twist - and we're also relying on intercepting events sent to a TelSet from a PC (or similar) - So we either need to itnercept and interpret the non-standard comms or rely on notifications. I wish you luck :)

Basiclife 2010-08-13 17:05:52

Interesting - If you're considering going down the having a dedicated server route, you might get some mileage from Asterisk - I haven;t used it much myself but believe it's highly customisable - Perhaps you could sit it between the PBX and the agents? It might give you the layer of abstraction you need

Basiclife 2010-08-13 17:07:51

ansaurus

tags:

views:

answers:

Open a web page when I receive an incoming call

related questions