The second part below is what I think I am interested in. I'm assuming voicemail would be one of the likely cases where latency issues would show up. Is there a magic number as far as ping times that are acceptable between the handsets and the server? Gateways would be local to the handset. I also need to figure out if I can leverage the windows server (described below) at the site as the gateway and/or for whatever else ends up being required at the remote sites.
There is no call routing between sites right now. They actually pretty much only call the corporate office, so I think I could handle that without too much trouble. Thanks, Matthew Picher, Michael wrote: > If you need a distributed env. right now I'd probably go separate pbx's > and setup call routing between them. > > If you can live for a bit with a centralized config for voicemail / etc, > then a single sipx or ha setup will work. You can then use locations > (user groups) to specify dial out gateways properly. > > Mike > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Monday, November 30, 2009 10:58 AM > To: Picher, Michael > Cc: [email protected] > Subject: Re: [sipx-users] Best practices for a branch office > > 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/
