Anyone every done this? Maybe from Altigen or another phone system?
Just looking for the best way to handle this.

On Jun 30, 7:31*am, mlu... (AT) doxgroup (DOT) com wrote:
By "screen pops" ... do you mean "screen pop ups"? And if so, what do
you intend "doing" in the popup --> what is the objective ('cause you
can do all sorts of "nice" things, given the fact you can execute any
CMD).

mlucas wrote:
Yeah, I've done that and it's a shame you should bring up the topic on
the eve of my usenet access going away - I won't be able to discuss it
here after today. I've been doing a lot with phone control lately:
- handling inbound calls
- making outbound calls
- inbound/outbound SMS backed by code like any other UI

At the end of the day it's all just data. Accept the inbound calls
with your PBX of choice (or talk to me about doing something new and
Very inexpensive) and incorporate that data into your app. Clients
must poll the system occasionally to be aware of new inbound calls.
When you have a list of calls and the user clicks one, you need to
feed the PBX an instruction to transfer the call to the call center
rep. How you do that will be different depending on the software
involved. If you're using Skype your call center people can be
located anywhere. Or, again with more software, you can route calls
to specific people no matter where they are simply by tracking which
number happens to be assigned to them at the moment.

There are so many angles on this. Unfortunately after so many years
of beating my head against the MV wall (we want it for free from the
DBMS vendor) my latest efforts only include MV for testing and I'm
writing these phone/SMS interfaces for a more general audience. For
the right opportunity however I'd be happy to redirect efforts.
Inquiries are always welcome. See my Twitter page (and soon blog) for
related notes.

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno

On Jun 30, 4:11*am, Cox Subscriber <c... (AT) users (DOT) invalid> wrote:

Why so cryptic? Just post the link to http://twilio.com

It's no secret.

--
Kevin Powick

Kevin Powick wrote:
Twilio is a tool. It's a car I drive to get me where I need to go.
Some people don't care what car I drive, they just want to get where
they're going. If they have a lot of luggage I might use a different
vehicle - there are other phone/SMS/PBX tools than Twilio. My
business is focused around helping people to get where they're going
without having to understand the underlying tools - without needing to
know the gas milage of the vehicle I drive.

It's been my experience that people here don't do tools, they want
nice finished products. I don't want people to look at a tool like
Twilio and say "I don't understand it therefore I can't use it." So I
try not to lead with tools but to lead with solutions. I'm building
solutions around Twilio but the more I get into that the more I
understand competitive and ancillary offerings - which I may add to my
kit.

I'm rarely intentionally cryptic. I've just done this long enough to
know that mentioning too many specifics turns discussions down paths
of digression, and away from the main goals and productivity.

T

On 2010-06-30 18:02:45 -0400, Tony Gravagno <nospam (AT) nospam (DOT) invalid> said:

Right. So you were thinking of something other than Twilio when you
posted the reply?

Well, instead of assuming we're probably not bright enough to
understand, you could have just said something like, "I've been doing a
lot if interesting work with Twilio that might fit your needs. Drop me
a line if you would like to discuss this further."

But, what else is there to do here at CDP?

--
Kevin Powick

C'mon Kevin, don't be such a cynic!!

(hmmm, might have a point at that!!)

On Jun 29, 3:31*pm, mlu... (AT) doxgroup (DOT) com wrote:
If you architect it right, you can make it highly scalable and you
won't have to do "polling". Eg. A CTI application that I did for the
US. Census 2000, had to handle 6000 agent workstations across 30 call
centers (7-timezones) and 7-different PBX switches. Despite the
scale, the solution is fairly common: The client workstations
stations were largely a browser-interface (wrappered inside of a light-
weight C++ application (any desktop technology should work) in-part
to lock down any Agent accesses to their other applications on the
desktop, but mostly to receive CTI push events (from a bridge server)
for preempting new browser pages, or to transmit browser states (when
certain application page(s) were reached; also useful to transmit
heart-beats for communicating system health and/or applying fail-over
technologies.)

Try to think of the fundamental problem as being a "state-driven
workflow engine" (around a logical/physical "bridge" server used to
'consolidate' and 'propagate' state.) The bridge server needn't be
centralized (ie. it could reside in logic managed distributively at
the client, however there are advantages in centralizing.) When calls
come in from the cloud (including possibly via IVR front-ends,
outbound dialers, or are transferred from other Agents; or the caller
initiates a hang up; et al) the bridge would receive events (state-
changes) sent from the PBX and/or IVR data. When Agents are
"available" (within the browser application, ie. whether at a post-
login page, or post their manually dispositioning a previous phone
call) ie. when the browser will arrive at a certain page(s) -- that
indicates the Agent is "ready" (as seen by the C++ wrapper which
processes this navigation monitoring event and propagates it to the
bridge workflow engine. Also, the PBX (upon an agent putting their
headset into available state, "on hold", or hanging up...) would cause
an event to the bridge server (which may elect to propagate such
outward.)

Effectively, the bridge server (or like functionality) is used to
receive the event(s) from the PBX (for caller-side events, Agent-side
events), dialer events, IVR events, the desktop (browser) Application
events -- and upon processing the events against its current state,
can push back (disposition) events to any of the above.

eg. One straightforward thread is: an incoming call goes to an IVR,
the caller navigates the menu and/or answering certain IVR
questions... subsequently requesting transfer to an agent. The
conditions which satisfy that an Agent is "available" (as per both
their telephony and their application desktop) -- is present at the
PBX and when the PBX transfers the call to the Agents telephony
device, the bridge server is informed and then pushes an event to the
appropriate C++ (in our case) control wrapper to pop the CTI
information (ANI and IVR variables) via interjecting such into the
browser application (that may subsequently cause a further server-side
data-dip and/or additional workflow logic to retrieve extra
information as a result of the padded browser request.)