<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thanks for the info. It got me digging deeper. I definitely don't
    want to screw this one up, but I've got to pinch pennies to get this
    done, so don't want to buy anything that would just be nice to have.
    ...but if I have to get it, that's what I'll do.<br>
    <br>
    Have any of you seen this? <cite><a class="moz-txt-link-freetext" href="ftp://download.intel.com/design/intarch/PAPERS/318862.pdf">ftp://download.intel.com/design/intarch/PAPERS/318862.pdf</a><br>
      <br>
    </cite><cite>It's a whitepaper from Intel where they load tested
      Asterisk on various Intel Processors. They were trying to show the
      benefit of compiling Asterisk using their compiler vs. gcc. It's
      from January 2008. They used Astertest as the test base. With a
      dual Xeon 5335 @ 2GHz (dual quad cores), and using a gcc compiled
      Asterisk, they were able to process 673 concurrent calls with GSM
      to iLBC transcoding and 552 calls with GSM to Speex transcoding.</cite><br>
    <cite></cite><br>
    <cite>Looking at <a class="moz-txt-link-freetext" href="http://cpubenchmark.net">http://cpubenchmark.net</a>, I see a dual Xeon 5335 @
      2GHz has a Passmark score of 5,095. A more modern single E5-2630
      processor has more than double the score at 10,401.<br>
    </cite>
    <p><cite></cite></p>
    ...and those results were with whatever version of Asterisk was out
    and about in January 2008. Would it be 1.4? From what I read here
    <a class="moz-txt-link-freetext" href="http://www.voip-info.org/wiki/view/Asterisk+dimensioning">http://www.voip-info.org/wiki/view/Asterisk+dimensioning</a>, Asterisk
    1.6 is 3-4 times better in performance than 1.4, and 1.10 is 2-3
    times faster than 1.8.<br>
    <br>
    Also, keeping in mind while yes I have 800 SIP phones, only 200 will
    be active concurrently at peak times based on current call traffic
    data, and I'm adding 50% to cover myself and looking to build to
    support 300 concurrent calls. Finally, throw in the fact the main
    Asterisk Server will not be doing any transcoding. The only
    transcoding will be in the PRI Gateway server, and with 3 PRI's, I
    only need the power to transcode 69 concurrent calls from G.711 to
    G.722.<br>
    <br>
    The next concern is the raw number of actively registered phones. I
    guess this is something I don't understand what the repercussions
    are, and I know the unknown is always what bites you. What happens?
    I wouldn't think that's a lot of open port traffic to worry about?<br>
    <br>
    <br>
    Thanks Again?<br>
    <br>
    <br>
    On 5/6/2012 3:19 PM, Mitul Limbani wrote:
    <blockquote
cite="mid:CAAoGpGRhZYFm-AHnkxfBVbM9MR1UVHpXoXWE5EFWyJqug87FDg@mail.gmail.com"
      type="cite">
      <p>For 100% High Availibility and Hot Failover, I would recommend
        one of those Red-fone Fonebridges.</p>
      <p>Also getting 800 Phones all register on single server is crazy,
        add a SIP proxy to distribute load evenly between 2 Ast boxes.</p>
      <p>For Wireless you might consider using DECT phones from Snom
        instead of std 802.11 based wifi phones. Giving QoS on wifi is a
        big pain.</p>
      <p>Hope that helps,</p>
      <p>Regards,<br>
        Mitul Limbani<br>
        Enterux Solutions</p>
      <div class="gmail_quote">On May 6, 2012 11:34 PM, "Nunya Biznatch"
        &lt;<a moz-do-not-send="true"
          href="mailto:asterisk@ihearbanjos.com">asterisk@ihearbanjos.com</a>&gt;
        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000">
            <p style="margin-bottom:0in">I'm about to receive approval
              to design and deploy an Asterisk-based phone system for my
              company. I will immediately have to start writing
              specifications. I'm working on the hardware design and the
              architecture right now. I'd like a second, third, fourth,
              1,000th opinion.</p>
            <p style="margin-bottom:0in">800 SIP phones. All will be
              G.722. I expect 200 concurrent calls, with 20% leaving to
              the outside world. There will be another 200 analog lines
              that will for the time being remain on the TDM PBX switch
              they reside on, and will be whittled down and converted to
              SIP as time and attrition allows. These are primarily fax
              machines and conference "spider" phones. Those are
              included in my 200 concurrent calls number. I'm looking to
              get as close to 5-9's reliability as I can, with 4-9's
              mandatory. Proper power filtering and backup is already
              available.</p>
            <p style="margin-bottom:0in"><br>
            </p>
            <p style="margin-bottom:0in">Here's what I'm thinking for
              the architecture:</p>
            <p style="margin-bottom:0in">Server 1: PRI Gateway 1 -
              Support 2 outside PRI trunks for local and long distance,
              plus a third PRI connecting to the existing TDM PBX.</p>
            <p style="margin-bottom:0in">Server 2: PRI Gateway 2 -
              Support 1 PRI trunk for local and long distance with room
              for another, plus a second PRI connecting to the existing
              TDM PBX.</p>
            <p style="margin-bottom:0in">Reason for two PRI Gateways is
              for redundancy and fail-over, but processor capabilities
              is a concern. I expect in about two years I'll be ready to
              decommission the TDM PBX, but will be left with about 80
              Analog lines across the multiple buildings on my campus. I
              expect I'll end up purchasing channel banks to support the
              remaining analog lines, and distribute across the campus
              using existing copper plant.</p>
            <p style="margin-bottom:0in"><br>
            </p>
            <p style="margin-bottom:0in">Server 3: Asterisk Master
              Server</p>
            <p style="margin-bottom:0in">Server 4: Asterisk Slave Server</p>
            <p style="margin-bottom:0in">I'm considering a clustered
              environment, but I believe a fail-over solution would be
              easier to implement in the short term. This means each
              system needs to handle all traffic by itself. These
              servers will be used for Asterisk and Voice-mail.
              Conferencing will be enabled, but I'm not considering it
              in the build. If I see conferencing becoming a factor, I
              will build another server and offload that service.</p>
            <p style="margin-bottom:0in"><br>
            </p>
            <p style="margin-bottom:0in">Server 5: Boot Server - DHCP,
              RADIUS, SNTP, DNS, LDAP, FTP, HTTPS, SNMP, etc... <br>
            </p>
            <p style="margin-bottom:0in">This service will provide the
              phone network all the basic services. This is a
              stand-alone phone network primarily because it would be
              too costly to upgrade the entire data network to support
              both voice and data. The phone network will not initially
              have Internet Access. This server will be the server all
              the phones talk to for pulling their configs.</p>
            <p style="margin-bottom:0in">I'm considering a second Boot
              Server for redundancy, but since the phones should store
              their configs, I'm not seeing this as horribly critical.
              Am I smoking something?<br>
            </p>
            <p style="margin-bottom:0in"><br>
              Finally, I'll have a Windows-based workstation that will
              be used to remote into all the services, for
              administration, etc...</p>
            <p style="margin-bottom:0in">I need to plan to use FreePBX
              on all Asterisk Servers, but I don't intend to install it
              until I'm in regular MAC maintenance mode.<br>
            </p>
            <p style="margin-bottom:0in">I have no plans at this time to
              build out any databases. I just plan to use whatever
              Asterisk has. If it ever comes to that, I would make those
              separate servers as well.<br>
            </p>
            <p style="margin-bottom:0in">My goal is to build Asterisk
              Servers and PRI Gateways capable of supporting 150% of
              what I anticipate, which would come out to 300 concurrent
              calls. Again, all phones will use G.722. The PRI Gateway
              servers will do the heavy lifting of converting G.711
              traffic from the PRIs to G722, and connect to the Asterisk
              Servers via IAX2 trunk.<br>
            </p>
            <p style="margin-bottom:0in">It's my intention to build each
              server myself with high-quality off the shelf components.
              I'd like all servers to be as close to identical as
              possible, as I intend to keep spares on hand to facilitate
              quick repair and minimize downtime. I'm considering RAID 1
              + 0 (mirrored and stripped drives) for all servers. I am
              considering dual redundant power supplies.<br>
            </p>
            <p style="margin-bottom:0in">For a processor, I'm currently
              looking at the i7-3770K @ 3.5GHz or very similar. Its
              Passmark compares to the Xeon E5-2630 @ 2.3GHz, but is
              half the price.<br>
            </p>
            <p style="margin-bottom:0in">I have no idea what amount of
              memory to consider, so I am thinking 8GB per machine.<br>
            </p>
            <p style="margin-bottom:0in">PCI-E is what I plan for all
              the cards.<br>
            </p>
            <p style="margin-bottom:0in">Debian is the Linux flavor<br>
            </p>
            <p style="margin-bottom:0in">A new network will be deployed
              using PoE layer-2 managed switches. Battery backup capable
              of providing 8 hours will be installed as required. There
              will be multiple VLANs in the network as I have multiple
              dissimilar offices I need to keep separated from each
              other. We will also have 802.11 SIP phones, and will be
              deploying a campus-wide WiFi network used only by the
              phone system. Yes, I crunched the numbers. This will be
              significantly cheaper than upgrading the entire existing
              data network to support the new phone system. ...and to be
              quite honest, I don't trust our network folks, and know
              adding that layer of bureaucracy will only negatively
              impact the customer experience. I was a network engineer
              for a top-three telecom company for many years, so I do
              have a point of reference to make those statements. <br>
            </p>
            <p style="margin-bottom:0in">...yes, I am one guy looking to
              do all this, with an estimated completion date of the end
              of 2013. I'll be building all this out in addition to my
              normal "phone guy" job. I've built servers (hardware and
              software) for 20+ years, but my Linux Kung Fu is weak.
              I'll be learning by doing and know there'll be a lot of
              extra hours. The boss is good about training, so I hope I
              can get into a good Linux Admin class in addition to dCAP.<br>
            </p>
            <p style="margin-bottom:0in"><br>
              So tear it up! What do you think? Does the CPU have the
              oomph? What am I missing? What am I overkilling? What
              would Brian Boitano do?<br>
            </p>
            <p style="margin-bottom:0in">I appreciate any feedback, and
              thanks in advance.<br>
            </p>
          </div>
          <br>
          --<br>
_____________________________________________________________________<br>
          -- Bandwidth and Colocation Provided by <a
            moz-do-not-send="true" href="http://www.api-digital.com"
            target="_blank">http://www.api-digital.com</a> --<br>
          New to Asterisk? Join us for a live introductory webinar every
          Thurs:<br>
          &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <a moz-do-not-send="true"
            href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
          <br>
          asterisk-users mailing list<br>
          To UNSUBSCRIBE or update options visit:<br>
          &nbsp; <a moz-do-not-send="true"
            href="http://lists.digium.com/mailman/listinfo/asterisk-users"
            target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --
New to Asterisk? Join us for a live introductory webinar every Thurs:
               <a class="moz-txt-link-freetext" href="http://www.asterisk.org/hello">http://www.asterisk.org/hello</a>

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a></pre>
    </blockquote>
  </body>
</html>