<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    IANAL but I think the behavior you are seeking is essentially a
    choke trunk, and so is perfectly legal. <br>
    <br>
    In the acme there are session constraints that can be applied at a
    per-agent and per-realm level, but I am not aware of any
    functionality to apply session limiting by originating or
    terminating number. <br>
    <br>
    Some strategies you might try using session constraints:<br>
    <br>
    If the traffic can be isolated to be coming from a specific session
    agent, you can apply constraints there, limiting calls per second
    (with burst capacity). When that call per second rate is exceeded,
    the SD will send back 503's to the agent in response to all new
    requests until the rate across the tolerance window falls. <br>
    <br>
    If the traffic comes from a wide range of agents, applying it at the
    agent level still leaves an aggregate throughput high enough to
    choke you, so you might consider putting those agents into their own
    realm and applying it at the realm level (or sub-realm if you dont
    want to give it its own media resources). Be aware when the
    constraints are hit in this case the SD rejects anything in that
    realm until it falls sufficiently. <br>
    <br>
    If all your inbound comes from a common provider so you cant just
    pick it out by session agent, then a third option would be to ensure
    your origination and termination traverse different core-side realms
    and apply your rate limiting there, so even in a flood scenario
    where your inbound is being flooded, and the SD is doing damage
    control on your origination trunk by rate limiting to the switch at
    the egress realm level, you would still have unimpeded termination.
    Below is a quick <br>
    <br>
    Provider ---> SBC ---> Core-origination realm (constraints
    here) ---> Softswitch<br>
    Provider <--- SBC <---- Core-Termination realm
    <------------------------- Softswitch<br>
    <br>
    In the scenario above it is important to break it out like this even
    though the SD does have different inbound and outbound constraint
    settings since the realm/agent will be taken out of service when the
    constraint it hit. <br>
    <br>
    <br>
    <br>
    On 02/20/2012 07:52 AM, Keith Croxford wrote:
    <blockquote cite="mid:4f426c2e.f177440a.48f9.ffffd7c2@mx.google.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 12 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">I'm looking for input from other voice
          providers: <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">We have an off-net number that periodically
          floods our network with inbound calls. When this happens our
          NS ( Broadsoft) often reaches or exceeds the number of
          available licenses. The end result is that new call requests
          fail until the call volume decreases. This usually last for
          5-10 seconds.  <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">We  have a cluster of AcmePacket SBCs in
          front of Broadworks. Does anyone know if it is possible to
          limit the calls per second on a dynamic originating number? I
          say this as the originating caller might be 555-555-1111 for
          10 minutes, then another flood of calls originates from
          444-444-2222 a few hours later. We believe these to be from
          the same caller due to the IVR message presented. <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">If it is  possible would the AcmePacket SBC
          perform this as an HMR in software, or would the SBC hardware
          handle this?   If the SBC cannot do  this, is it possible to
          perform some sort of dynamic rate limiting on a Broadsoft NS
          and send a failure response code w/a reason code after a
          metric is breached?  Any other suggestions would be great. <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">The last question involves legal
          implication of blocking a number. Assume that we  blocked all
          calls from 555-555-1111 at our SBC.  Two weeks from now
          Customer A opens a trouble ticket that their customer cannot
          call them. Of course the company’s main line happens to be
          555-555-1111.   Is there any FCC rule or regulation that would
          limit this. I'm trying to find something in  Title 47 of the
          Code of Federal Regulations… <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Thanks!<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Keith <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
    </blockquote>
  </body>
</html>