Matthew, if you want this sort of config, what you really want is the first option I described and not the second option.
Don't bother to try and get sipXecs to run in Windows (you'd have to compile it on your own on that platform and I don't know anybody doing that). You could run it in VMWare ESXi 4 like you are describing but do as Tony said with the hard drives and expect that you will possibly have voice recording and AA issues. Convert to version 4.2 when it comes out and setup the branches with it (you may want to wait for 4.21 for a production environment / depending on if you can wait). Note that in general we do not recommend running sipXecs in VMWare. Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, November 30, 2009 5:32 PM To: [email protected] Subject: Re: [sipx-users] Best practices for a branch office That is what I want do. I'm not clear on whether or not -sipXecs can run on Windows -sipXecs could run on free VMWARE ESX running on top of windows (it wouldn't be heavy usage) -If I could use centralized voicemail with 70 ms ping times. (much more detail at the bottom of this email, but that is the quick summary) -Matthew Todd Hodgen wrote: > If you make that unused Windoze server another instance of sipXecs, then you > can do sipXecs-sipXecs trunking between these two offices, and begin to lay > out your extended dialing plan for all of these offices. > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Monday, November 30, 2009 2:10 PM > To: Picher, Michael; [email protected] > Subject: Re: [sipx-users] Best practices for a branch office > > 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/ > > _______________________________________________ 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/
