Ah... too bad 4.2 isn't further along...
-----Original Message----- From: Matthew Kitchin (public) [mailto:[email protected]] Sent: Sunday, November 29, 2009 5:17 PM To: Picher, Michael; [email protected] Subject: Re: [sipx-users] Best practices for a branch office Thanks. I'm not too worried right now about the sites that are keeping their current pbx. Lucky for me, Verizon is covering the cost of the equipment and installation. My urgent need is how to set up a remote sipx setup at a branch office. -----Original Message----- From: "Picher, Michael" <[email protected]> Date: Sun, 29 Nov 2009 16:36:41 To: <[email protected]>; <[email protected]> Subject: RE: [sipx-users] Best practices for a branch office Hi Matthew, I'd use some Patton SmartNode 4118's out at the remotes with either 8 fxs or 4 fxs / 4 fxos. Either that or the SmartNode 4520 series has dual Ethernet interfaces allowing for one on your MPLS network and one on your internal network (firewalling in box). This may get you around some NAT hassles at certain sites. That's all you really need for your initial goal of getting the old PBX's some SIP traffic. Then as you get familiar with the SmartNodes you could get into some fancy call routing and do some least cost routing between your offices by tying the SmartNodes back to your sipXecs server. Another approach might be to use some analog line cards in the Cisco Routers (if they have slots available). You can hand SIP off to the router and have the router connect to your PBX with some analog station lines. Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Sunday, November 29, 2009 4:14 PM To: [email protected] Subject: [sipx-users] Best practices for a branch office I'm having to put the cart before (if not at least next to) the horse on this, but I guess that is the way it goes sometimes. I have a 4.0.4 ISO built system that is supposed to be fully functional tomorrow if Verizon can do their part by actually turning on our SIP service. I will be able to migrate users to it at my own pace over about 3 months. After that, it should have about 150 handsets. It is currently running on VMWare ESXi/VSphere 4.0 update 1. I intended on migrating it to a physical box before it really gets used because of the issues reported when running sipx on VMWare. My corporate office is in Nashville, TN. We have 110 remote facilities all over the country. They are each connected to our office by an MPLS T1with Cisco routers. They have a variety of phone systems. They all use POTS lines (usually 4 to 6) and have 12 to 14 handsets. My boss had already been sold on the fact these were converting to SIP from verizon before I even entered the discussion. They plan to put a device of some sort that will convert SIP to analog lines and leave all the phone systems untouched. The plan was deploy sipx at the corporate office, convert the remote facilities to VOIP without touching their phone systems, and then investigate how to handle new remote offices or ones that outgrew their existing phone system. Now things just got thrown out of order. The building owner at one of our facilities in Portland, OR wants us off their phone system now. I have a month or so to get it done, but I need to figure out what the best way to do it it. The remote offices can get directly to Verizon's cloud without going through our Nashville office. We definitely want to do that. We also want to keep our IT infrastructure as centralized as possible. There are no IT personnel at the remote facilities. We do have a relatively powerful and very under tasked Dell Poweredge or HP Proliant at each facility. It would be no more than a couple of years old, memory is not a problem, SCSI drives, hardware raid with cache, hardware remote access card, etc. They are running Windows 2003 server 32 bit. A few are running 2008 64 bit. If at all possible, I would like to use this server to accomplish whatever is needed remotely. It just seems like a waste to have that sitting there and not use it for sipx component if I can. After looking here: http://sipx-wiki.calivia.com/index.php/SipX_on_Different_Platforms I'm unclear on exactly what it could or couldn't do in Windows. If it can't run on Windows, I would be willing to load the free version of VMWare ESX on top of Windows if that was an option. I know about the potential issues with VMWare, but this is such a light load, and I haven't had any problems at my office under a similar load. If the experts on here are adamant that neither of those options are a good idea, I will certainly then look into something else. The next piece I think I need some good advice on is what components to put locally and the facility and what to run at the corporate office. If the MPLS circuit goes down, we expect the facility to be dead as far as the phone system. Not the best idea in my opinion,but that is what I'm being told to do at the moment. There will likely be one POTS line with an emergency analog handset on it. The other issue is network latency. Oregon is our worst area with that issue. We get about 71 ms ping times from our corporate office in Nashville to a Oregon clinic. I wish I didn't have to start here, but oh well. The speeds don't drop when it is heavily used and we will prioritize what ever traffic is needed. We have one app that does horrible with latency and it definitely shows up in our most remote facilities. I'm assuming this would be the factor that would dictate where we stored voice mail. I want everything to be as central as possible, but also perform as well as possible. We don't use any advanced features at all in our remote facilities. Sorry for the long winded email. Any tips or ideas would be greatly appreciated! Thanks, Matthew _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
