atcomsystems.ca/forum Forums TDM Business Telephone Systems NEC Telephones & Systems NEAX 2000 IPS Integration with Predicative Dialer

I have a customer that wants me to integrate my predictive dialer with their NEC system. Here is a scenario on the configuration I am thinking of setting up.

I will provide a SIP trunk (as far as the NEC is concerned) from my dialer. My dialer will then initiate a call to the NEC with a special DID that maps directly to a specific phone (extension 101 = DID 101, etc). And this would be all the integration needed.

My questions are as follows:
1) Does this sound like a good scenario as far as the NEC is concerned? Any suggestion on other methods?
2) What practical limits should I be aware of? I.E. the routing table in the NEC will only map X number of did's, etc.
3) Any special hardware needed on the NEC end of the puzzle?

I would think that the NEC system would have plenty of capacity and that this should be well within it's operational design. All the work will be performed by the customer's phone vendor but seeing as I don't know them I came here seeking some more trusted advice. I would also like to advise the customer on any gotcha's to look out for before just haphazardly proceeding with the integration.

As always, I appreciate your time and any feedback you may give. Thanks.

One thing to ask is:

Is the predictive dialer going request a login for the user of the NEC phone so the calls can be connected to the correct phone? Is the predictive dialer going to be able to read the particular messages sent from the IPS2000 showing a call idle, busy, or logged out?
What you are wanting to do sounds easy enough until pull back the hood so to speak.

As long as the IPS is up to SIP trunk s/w levels etc. it should be fine. If not, a T-1 set as TIE/DID will accomplish the same thing.

I can see where you are going. The system I have uses a web-interface to control the underlying dialer functions. As part of the web log-in procedure the agent selects the phone extension they are currently sitting at so that the dialer can call them on that phone.

So from start to finish the way it would work would be:

1) User logs into web interface and indicates phone they are at
2) Dialer initiates call to specific DID that maps to specific phone
3) Phone rings, agent picks up phone
4) Dialer handles the rest of the call features internally (music on hold, conferencing, park, transfer, etc)

By having each extension on the system also have a unique DID I can transfer and conference calls around to extensions that aren't "logged-in" to the dialer easy enough. This gives a fairly seamless appearance of transfer and conferencing. Parking would definitely be out of the immediate realm of possibility so I'll have to let them know about that.

The dialer doesn't get too involved in the status of the extensions because it uses a persistent connection to the agent while they are logged into the web interface. This means that if the agent is logged in for 4 hours they will have their phone off-hook for 4-hours as well. Also why I HIGHLY recommend headsets. Most of the host phone systems can easily enough indicate other phone calls coming into the phone so the agent can just "Pause" their session on the dialer, hit the hold button on their phone, then pick up the other line.

So what I need to make the customer aware of is that parking function between the dialer and their PBX wont work.

Based upon my expanded explanation of how some of the other parts work, does it still sound like a viable solution?

Ok, I see what you are saying. I saw this type of system setup on an old Toshiba. The only difference is it was using PRI instead of SIP trunks. The "agent" logged in thru a website and "registered" his or her DID number with the dialer. He or she then got the call when the system saw the DID was idle. Yeah, this should work.

Sounds good. I appreciate the feedback.

It's always nice to find a solution that works for me as well as for the phone system itself.