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/
