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

    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
     
    Doug, May 30, 2006
    #1
    1. Advertising

  2. In article <>,
    Doug <> wrote:
    >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.


    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
    #2
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike

    Limewire hogging cpu usage

    Mike, Nov 6, 2004, in forum: Computer Support
    Replies:
    1
    Views:
    1,955
    Dr Hackenbush
    Nov 6, 2004
  2. Tim Kett
    Replies:
    7
    Views:
    1,755
    @}-}-------Rosee
    Dec 17, 2004
  3. Mihai
    Replies:
    0
    Views:
    640
    Mihai
    Jan 7, 2004
  4. TJ
    Replies:
    23
    Views:
    11,213
  5. Piet  Slaghekke
    Replies:
    4
    Views:
    1,008
    Meat Plow
    Nov 10, 2006
Loading...

Share This Page