Verizon hasn't proven to be the easiest to work with, but I don't have a choice at the moment. They also have a bandwidth/proximity advantage over any other carrier with respect to our network. If they absolutely can't do what we need, I will then likely be able to pursue other carriers. But... How does the ITSP affect my questions regarding the ideal decentralized/centralized setup?
Thanks again for all the help and tips everyone provides. -Matthew Tony Graziano wrote: > The easier way for this to be successful is to find another ITSP though. > ============================ > Tony Graziano, Manager > Telephone: 434.984.8430 > Fax: 434.984.8431 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > ----- Original Message ----- > From: [email protected] > <[email protected]> > To: Picher, Michael <[email protected]>; > [email protected] <[email protected]> > Sent: Mon Nov 30 17:09:46 2009 > 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/
