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

Discussion in 'Cisco' started by Doug, May 30, 2006.

  1. Doug

    Doug Guest


    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

    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, May 30, 2006
    1. Advertisements

  2. 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.
    Robert Bonomi, Jun 1, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.