I will be glad to upgrade then, but I have to move forward with something now.
Picher, Michael wrote: > 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/
