On multi-app IVR, prevent one app from hogging all B channels

Greetings,

This is not a Cisco issue, but as a switch/router engineer at heart, I trust y'all to have a wide experience of networking. My posts in comp.dcom.sys.nortel and comp.speech.research have not gotten any hits.

We are getting ready to migrate multiple IVR applications from analog to PRI.

Each application will have a unique lead phone number with every lead number present on every PRI and even call distribution across all PRIs. The IVR software uses the DNIS dialed number to route each call to the correct application process on the correct server.

In the present system, concurrent calls are capped by the number of analog phone lines present for each application. We are migrating from this ancient system to a stack of servers with PRI cards and IVR software. Touch-tone and speech-recognition trees are being reverse-engineered and applications rewritten from scratch for a modern IVR platform.

We must have a boundary between the applications to prevent one app from taking over all B channels. I want to set a different concurrent call limit for each application. Call limits are also used for chargeback to our customers.

Having exhausted our telco asking how to do this, we have come to the conclusion that telco is not the right place to set these limits. The right place for the call limits seems to be in the application. I'm thinking that each IVR app would keep track of its concurrent calls and send an "all circuits busy message" to callers when the call-limit is exceeded.

To make a business case for application-based call-limits, I'm looking for support from someone familiar with best practice in this area. I'd settle for someone who has actually seen a multi-app, PRI-based IVR with concurrent calls capped for each app.

Doug

Reply to
Doug
Loading thread data ...

This is a no-brainer, relatively speaking.

Each app is going to have it's own incoming 'lead number'. Either you're going to have (effectively) a unique DID for each B channel, with the DIDs organized into hunt groups (sequential call-forward-busy) -- 1 'group' for each app, with the number of 'lines' assigned to the group being the maximum number of simultaneous calls allowed for that app (this basically parallels the existing analog line logic); *OR* you will have only one dialable number per app, with multiple 'call appearances' for that number (with each app. effectively "knowing" which 'buttons' to answer). If all the allocated 'appearances' for that number are in use, the next call to that number will get a 'busy' status -- effectively w/o any intervention by the

Either way, the functionality sits 'upstream' of the individual IVR program. In the first case, it is 'in hardware' and the C.O. switch. In the latter case, it's in the configuration of the line termination software in the 'supervisor' program, rather than in hardware.

Reply to
Robert Bonomi

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.