Announcement

Collapse
No announcement yet.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Limiting number of inbound call on DID

    Issue:

    This site has a PRI used mostly for outbound calling. The business wants to limit the number of concurrent inbound calls to the main number. Example:

    1) Concurrent callers 1-8 are answered by an IVR hunt group (8 ports available)
    2) Following concurrent callers 9-23 get busy signals

    With the older switches I've experienced this is pretty easy to setup; if the device or hunt group has no channels/appearances available, a busy is sent. The Shoretel system appears to forward to the AA in the event no channels are available on the AA hunt group.

    How can I make Shoretel originate a busy signal even if there are channels available on the PRI?

  • #2
    Call Control > Hunt Groups > "IVR Hunt Group"

    Set 'Call Stack Depth' to 8 calls and delete the 'Call Stack Full' destination. When there is no destination for a full call stack (tapped out at 8 calls), the system will play a busy tone for the 9th caller.

    Comment


    • #3
      Dr K.

      Thanks so much for the reply...

      Just for my info: will the busy originate from the CO (via D-channel busy) or from the switch?

      Thanks again.

      Comment


      • #4
        Ok, I tried it and it works the way I described in my initial post; however, I was not as explicit as I needed to be. The IVR is transferring the calls to other extensions and allowing more than 8 ports in via the DID number.

        Is there a way to limit concurrent call pegs on a DID?

        1) Concurrent callers call a DID number (1-8) and are answered.
        2) Following concurrent callers calling that DID number (9-23) get busy signals.

        If <8 callers dialing 903-555-1212(DID) are actively on a call, answer it. Else send a busy signal.

        Comment


        • #5
          Hmm...
          How about a Route Point with a call-stack of 8 and no Vmail?
          Route point forwards to your HG..

          I have never tested it this way, but it might work..

          Comment


          • #6
            Nothing involving call stack will work. In order for a call stack to fill up, the calls must remain on the extension with the limited call stack.

            I would recommend you work with your trunk provider. We have at least one customer whose provider limits inbound calls to a specific number of simultaneous calls.

            Comment


            • #7
              I am with palitto on this point, there is no way to reject incoming calls the way you are describing without getting your telco involved.

              Comment


              • #8
                I really appreciate all of your input. I have a call in with Shoretel and will let you know what we end up doing.

                If blocking is simply not possible with ST, one tenant could congest all ports on the attached PRIs in a multi-tenant environment. From my view, it's poor design to prevent Q931 from sending a busy from the called PBX if the station is busy and has nowhere to put the call. Also, an ATB should also be sent if a DID is not programmed. In our testing, everything seems to end up at voicemail regardless of an invalid DNIS.

                I could ask the DMS500 to pilot the main number with a dummy POTS forward group and limit concurrent forwards to 8. $$
                The other option that comes to mind is automate dropping the call after it is answered by the ST - like the Veterans Administration does... (Wow)

                Any other ideas?

                Comment


                • #9
                  UPDATE: ST tech told us it could be done. Gave us instructions:
                  "Create one 8 trunk group that only has those DNIS numbers for access - after all 8 channels are full, they get busy. Then creat another trunk group using the rest of the trunks and set the DID numbers that would go through it or configure the DIDs for each user with nothing at the trunk."
                  This didn't work either.

                  We took your suggestion and called the telco. They said it wasn't possible if the DID was assigned to the PRI. They created a soft port, set the forward stack to 8, and forwarded that number to any valid DID on the PRI. DNIS still passes when forwarded to the PRI. Looks like that's -a- solution.
                  The phone company stated that this is only a workaround. The PBX should send QSIG 17's over the D channel to send a congestion signal to the calling user regardless of the PRI status. I agree.

                  I asked ST to forward my ticket to a feature request.

                  Thanks everyone for your reply.

                  Comment


                  • #10
                    This is a feature we would like to see as well. I need to be able to signal busy back to the network over the D channel to limit concurrent calls per DID number.

                    I'm from a networking and computing background so I will admit that my understanding of ISDN and circuit switching is limited. These are my thoughts.

                    On a traditional PBX the PRI termination is connected to the backplane of the PBX, connections from end to end are switched so the call setup end to end is effectively a hard circuit. The processor on the PBX knows when a destination is free or busy and determines what signally goes back and forth down the D Channel.

                    The PRI gateway on any IP system is only loosely connected to the rest of the phone system via IP. The hard circuit is between the gateway and the rest of the world, the gateway is not really processing the call in the same way, it is answering the call and then it is pretty much assuming that there is an IP endpoint somwhere else to process the call and handing off the call to the next stage.

                    Comment


                    • #11
                      Interesting... While I agree that what you describe actually is, I don't fully understand why.

                      From a business (end user) viewpoint, the whole argument for IP over traditional PBX gear has been cost savings by the reduction of MACs and an ubiquitous medium (IP) to tie some offices together or a cheap way to service OPX. To me, this one step forward followed by 5 steps backward isn't a good approach to proving a business case for IP system X over traditional system Y. There's no reason to re-invent the wheel here... Regardless if a PBX system is IP, digital, or analog, it should forward, block, and service calls in similar business fashion.

                      I understand and identify with your position coming from a networking and computing background. To correlate this simple feature to an IP service: If your web server has 100Mb of bandwidth, you program your server send a "503 Service Unavailable" in case the application becomes abnormally overloaded with concurrent hits. Why would one design a phone system to be able to send 23 calls to a single-user extension without a blocking option is beyond my comprehension.

                      Design for the norm and plan for the extreme...

                      Comment


                      • #12
                        While I understand what you are saying, from a purely telephony point of view the solution to having all of your channels or trunks fill up is more trunk capacity. In more than 99% of cases business people consider giving a customer or associate a busy signal as anathema and will go to almost any ends to make sure it never happens. While I agree that the system should support the industry standard as described, practically speaking this type of feature gets little use where it does appear and is in fact not present of a great number of even legacy digital PBX systems. Again, I do not disagree, I just like to help clarify so we are all on the same page.

                        Comment


                        • #13
                          I would agree with you that in many *very important* business cases, call blocking is unacceptable; however, I disagree that businesses consider a busy signal unacceptable and make sure it never happens. There are some very notable, common, and significant exceptions.
                          Automatically implying that all calls are revenue-based and must be answered immediately is a misnomer. 4 out of 5 of my clients (80%) run cost-based call environments and prefer sending busy signals in place of 60-70 minute hold times on a toll-free number. I would venture to estimate that the vast majority of queue wait-time I personally spend on is in a cost-based queue. Call into a Billy Mays as-seen-on-tv commercial and I guarantee that it will be answered immediately! Now try calling customer service to send the item back... There are stark differences in queue times and philosophies.

                          People wait in line to give the cashier their money at places like Wal-Mart to checkout. Even though this queue is revenue-based, there is consideration given to staffing even when checkout capacity lanes exist or not.
                          If a customer wants to return an item, the queues are even longer. This is because customer service in this case is a cost-based queue a.k.a. not revenue generating.

                          There isn't much of a conceptual difference here concerning a phone call.

                          It is a business philosophy: either send a busy (something everyone understands) or clog the lines with some calming Mozart music and a broken record stating that "we value your call" for the next twenty minutes of someone's life. It's not right or wrong. It's a philosophy dictated by the business and for each case. Regardless, I strongly believe that this feature should be technically supported in ST.

                          I really want to thank everyone for their information and advice. I really do appreciate everyone's assistance here. I plan on frequenting this forum due to all the activity that I see here and the kind users/admins/installers that share information for the common good and understanding.

                          Comment

                          Working...
                          X