<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thanks to everyone for the responses. I really appreciate it. I'll
    answer all questions and suggestions in this one email. (at the
    bottom)<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 6/14/2013 9:43 AM, Nunya Biznatch
      wrote:<br>
    </div>
    <blockquote cite="mid:51BB3A21.9000903@ihearbanjos.com" type="cite">Howdy
      All,
      <br>
      &nbsp;&nbsp; They say opinions are like belly buttons, everybody has one.
      (that's the "clean" version of the saying). So I'm asking for
      yours. I hope you see it as a fun exercise.
      <br>
      <br>
      I'm designing a phone system from the ground up. Will be about
      1000-1300 seats mixed 80/20 VoIP/Analog. 58-acre campus
      environment with 23 buildings. Userbase is emergency services
      organization, 24/7/365 operation. Down time is not an option, but
      "blips" are acceptable. Repair time is immediate. We need failover
      for the failover essentially. However, money is a major factor, so
      I have to do it all for nothing. So here's what I'm thinking.
      Please throw in your 2 cents.
      <br>
      <br>
      Network will be separate for phones. Fiber infrastructure
      available between buildings as well as copper. Internet access
      will be limited to a single administrative console on a temporary
      basis, and then only when remote 3rd party support is required.
      Access for 3rd party support will be supervised through remote
      access tools such as VNC, GoToMeeting, etc... etc... System will
      have zero access to local data network. This means all ancillary
      support servers such as DHCP, DNS, NTP, FTP, etc...etc... will be
      specific to the phone system. Yes, I know some responders at this
      time will become fixated on me gaining this connectivity. It ain't
      gonna happen. It's not an option. Period, end of story. These are
      the parameters I must work within. Trying to "fix" that will be a
      non-starter.
      <br>
      <br>
      The phone system will upgrade an existing TDM-based system. Mitel
      SX2000 with NuPoint Voicemail. This will not be a dump-trunk
      replacement. I expect at least a one to two-year transition,
      meaning we will have time to find problems,&nbsp; work bugs, and learn
      over time, with minimized impacts. It also means we'll be
      supporting two systems for some time.
      <br>
      <br>
      PBX is 97% serving your basic phone on the desk. Nothing special.
      Customers expect the usual list of features. There will be a
      goodly number of hints required for BLF on maybe 150 phones. There
      is one office of about 30 phones in a call-center environment that
      will need that service. They would be considered low volume (but
      don't tell them that).
      <br>
      <br>
      My Skills... I am not a Linux kung fu master, but I have built and
      managed my share of Linux servers on mutiple Linux flavors. I am a
      DCAA, having been through formal training, and have been playing
      with Asterisk for years, but always in fits and spurts and never
      in a live environment so I am by no means a kung fu master there
      either. I have started dabbling with virtualizations via XEN, but
      I am not comfortable enough with it to go live this first round. I
      can see myself implementing it in about three years once we're
      totally comfortable with what we have, so I can then have time to
      get that skill sorted. I was a network engineer for the US no3.
      telecom for a number of years, 10-years in comm-electronics in the
      military before that. Telecom my entire career. I've got the
      kung-fu to handle the network side of the house, and having
      administrated multiple PBXs for decade-plus, I've got the concepts
      down.
      <br>
      <br>
      No plans to build databases for things like directories, etc...
      I'm not greatly confident in those skills, and to date, haven't
      found anything that really stands out that would make me require
      that. You may think otherwise, so please chime in. I say that, but
      at the same time I recognize I may require a GUI interface once
      fully deployed to allow lower-skilled people to follow the motions
      to complete simple moves, adds, and changes. I'm fighting the
      uphill battle that is the "GUI is new, CLI is old" mentality.
      <br>
      <br>
      System will use G.722 for VoIP Phones.
      <br>
      <br>
      So there's the groundwork. Here's the hardware plan.
      <br>
      <br>
      Plan is to build my own servers following industry standards (ATX)
      and using industry standard equipment. Why? Spares? Whether
      redundant or not, I will still have spares for the most common
      elements on the shelf so equipment can be returned to service as
      quickly as possible. This will also allow me to be comfortable
      with more "basic server" configurations and help keep cost down.
      For example, Servers with single power supplies vs. dual. Also,
      components will be standardized for all equipment to aid in supply
      requirements.
      <br>
      <br>
      First the layout.
      <br>
      <br>
      2-servers acting as gateways. Each handling 2 PRIs for outside
      trunks. They'll also handle the analog ports. Failover will be in
      the form of degraded trunk access if one should fail, but the
      second will be able to support services in degraded fashion.
      <br>
      <br>
      2-servers acting as VoIP PBX. A primary and a spare. Meaning one
      will be capable of handling the load of the entire system, and the
      other will pickup when the other dies, an active/passive cluster.
      Will also take care of voicemail. Use of heartbeat, pacemaker,
      etc... etc...
      <br>
      <br>
      2-servers for support services. DNS, DHCP, FTP, NTP, etc...
      etc...Basically, everything the phones need to run plus system
      monitoring via something like Nagios.
      <br>
      <br>
      1-Desktop for administration of everything. Provided from
      corporate. Basic Desktop.
      <br>
      <br>
      Looking at Intel Xeon E3-1230 ivy-bridge processors. 8GB DDR 1333
      for Gateways and 16GB for PBX and support servers. 1TB drives in
      RAID 10 via LSI 3ware 9650 cards for PBX, 250GB for Gateways.
      Supermicro X9SCM-F mobo.
      <br>
      <br>
      OS of choice is Debian. Primarily because it appears to have the
      best availability for non-Internet installations.
      <br>
      <br>
      <br>
      Now the Infrastructure
      <br>
      <br>
      <br>
      2-network switches in the phone room. Each set of "primary"
      servers to one, and "secondary" servers to the other, and each
      switch connected to the other. Each switch will have a different
      path to the network. RTSP implemented for dual path to the campus.
      Only one location on campus will have or require dual paths to the
      network.
      <br>
      <br>
      Most buildings on campus have cat-3 for voice installed in the
      mid-90s. Wired at the same time as the data network, I can
      generally conclude they're the same length. It's terminated to
      110-blocks on walls. Some cabling is only 2-pair. I know I will
      find surprises. Essentially, I plan to re-use this cable, knowing
      in some circumstances I will need to make special patch cables.
      These connections will be forced to 10BaseT at the switch.
      <br>
      <br>
      I require PoE to the wire closets, no power sourced at the
      desktop. I require a minimum eight-hours emergency power which
      will be in the form of UPS in most cases. Why so much backup? Well
      if you ask, we can start a new discussion about NEBS compliance,
      E911 Federal, local, and state requirements, etc... etc...
      <br>
      <br>
      So why not use existing data network? The current data network
      consists primarily of 10+ year-old 100BaseT switches, no PoE.
      Barely any backup power. I don't believe they're using QoS. The
      network office is a separate department from the phone office. I
      question their skills, and above all, network folks treat phones
      like computers, not like multi-million dollar lawsuits when they
      don't work in an emergency. We could make another thread out of
      this huh? To use existing data network would require hundreds of
      thousands in Cisco 6500 and 4500 series switches. Network has
      already stated they'd want phone on separate ports from computer,
      and I agree. (Yet another thread). Thousands of computers across
      23 buildings, and it must be Cisco by corporate policy, where
      phone is a different animal that doesn't have this limitation. You
      can see we're talking hundreds of thousands in just switching
      gear. Then UPS requirements to support a big hog of a switch vs a
      teeny 48-porter w/PoE, and you just cranked up one-time and long
      term cost for that as well. Trying to replace the network to
      support the phones is cost prohibitive and a non-starter. Maybe we
      can talk about it in 5 years once they've replaced everything.
      <br>
      <br>
      I plan to purchase lower-cost Layer-2 smart switches from vendors
      such as DLink, Xyxel, Dell, etc... Many players in the market for
      48-port switches with PoE and multiple SFP.
      <br>
      <br>
      I think that's probably enough... I apologize for the large email
      but I couldn't think of a better way to get a qualified peer
      opinion without laying out the facts.
      <br>
      <br>
      Thanks in advance for your review and consideration...!!!
      <br>
      <br>
      <br>
      <br>
      <br>
      --
      <br>
_____________________________________________________________________
      <br>
      -- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="http://www.asterisk.org/hello">http://www.asterisk.org/hello</a>
      <br>
      <br>
      asterisk-users mailing list
      <br>
      To UNSUBSCRIBE or update options visit:
      <br>
      &nbsp; <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a>
      <br>
      <br>
    </blockquote>
    <br>
    <br>
    Daniel Asked:<br>
    <pre wrap="">"So why use g722? Just use your local g711 law and thus avoid the
transcoding impact to/from the PSTN and calls between the voip and analog
users."</pre>
    Answer - Wideband codec is a requirement. This is a value-added
    expected from the user-base.<br>
    <br>
    Daniel Asked:<br>
    <pre wrap="">"And why would you seperate the PBX and PRI machines? Those few extra
channels don't really matter."

Answer - There's a couple reasons I'm thinking this way, which may be misguided so thanks for making me think about it. First is redundancy. Offloading the PRIs and analog phones from the primary PBX means if there's an issue, I can take one of those PRI boxes down and not affect the PBX, and the other PRI box will continue to provide trunking services. Only the analog lines on that specific PRI box would be impacted. Second, I know I'll be transcoding G.711 to G.722 on those machines, 46 PRI channels, and 48 analog lines. I've been unable to find anything solid that gives me a definitive idea as to how much horsepower I need. I'd rather find out I have too much then decommission one of these servers down the road, than to not have enough and kill the entire system. Where I work, Asterisk is a massive paradigm shift that'll be attacked every time there's a problem from all angles from every vendor and salesman, in addition to the internal Cisco crowd, so it must be rock solid. I did
n't think this was the place to take that risk. Finally, is my own ignorance. Both PRI boxes will service the active PBX. I don't have the knowledge to put half the PRI cards in one PBX, the other half in the other, then have the trunks from the inactive PBX serve the active. I know I'll figure it out once I've had the opportunity to get deep into it in a live environment, but there's still the desire to be able to drop the computer that serves the PRI without impacting the PBX.


Steve Wrote:

"<a href="http://red-fone.com/products-new/fonebridge/">http://red-fone.com</a>&nbsp;might
 be a good place look and see if other ideas pop up. &nbsp;They have good 
products. &nbsp;I am not affiliated with them, just a happy user on a couple 
of deployments. "

Answer - I'd looked at Redfone previously. My concern with them was cost, functionality, and their website makes them seem a little stand-offish and looking for long-term monies. If I offloaded my PRIs to two dual-PRI foneBridge's (to retain redundancy), I'd still need at least one server for the analog ports. Also, I'd need to purchase a 3rd foneBridge as a cold spare. ...and maybe they have total solutions for all that, but they're not forthcoming via their website. Their website looks as if they're trying every avenue to get me to call them so they can pimp their wares. Limited Documentation, no manuals, nothing. It's all "contact us for more information". I translate this to mean, "We'll sell it to you with high-pressure tactics. Then, once you own it, we're going to sell you a support plan and not talk to you unless you have it." Maybe all of that is completely untrue, but there's no way for me to tell, and I'm not one who's willing to find out. Actions speak louder than words.
 I understand they need to make money, but their website reflects their style, and they aren't the style I work well with. Oh, and they insist on ssh with root/su privileges. Ain't gonna happen.


Terry Wrote:

"<span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Another
 option instead of 2 servers dedicated as PRI gateways is to use 
AudioCodes Mediant 1000 or 2000 gateways.&nbsp; Either of them will also 
failover to a backup proxy if the primary proxy (server) is offline.&nbsp; 
Probably much cheaper than the kick ass box you plan to build + PRI 
card(s).<o:p></o:p></span></pre>
    <span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I&#8217;m

      not affiliated either, but we do place them in our 911 call
      centers.&nbsp; They have analog gateways as well for FXO &amp; FXS
      devices."</span>
    <br>
    <br>
    Answer - I hadn't seen these guys before. Thanks. Unfortunately, I
    see them doing the same thing as RedFone. They appear to have the
    information, but require me have an account and login to get to it.&nbsp;
    I don't want to find myself beholden to any hardware vendor. I went
    to register for access, but they want a specific business
    relationship noted. This is a red-flag for me. We're already in a
    relationship with Mitel where we can't get anything done without
    going through local support Mitel mandates to us as part of the
    service contract. There is only one company in the area that is a
    Mitel service provider, and they are less than worthless. As far as
    cost, I'm trying to see the numbers, but I'm not having much luck
    making them fit since there's nowhere I can find at quick guide that
    will let me build what I need. The server I plan to build is around
    $1600. That includes RAID 10 with battery backup on RAID, 8GB ECC
    memory. E3-1230 processor. All brand name stuff and motherboard
    recommended. Add a single dual-span digium card (not promoting, just
    example) with echocancelling, and I'm looking at around $2900.
    Closest replacement to that I can find in AudioCodes is the M600/2
    span. Looks like it's hovering at around $3500. Yes there are many
    more moving parts in the server, and there is the entire unknown
    about piecing together a system that makes me uncomfortable, but
    spares are pennies that can be spread across all servers vs. a cold
    spare for the M600 and I'd still need spares for the PBX.<br>
    <br>
    <br>
    <br>
    Thanks again to everyone. It's making me think and work through the
    issues and concerns, which is what I needed.<br>
  </body>
</html>