If Verizon provides the ds3 internet pipe, then you can chose any ITSP for providing your SIP trunks. Other carriers are more user friendly with regards to supporting other ports, etc.
And, many have user portals that allow you to control your destiny a bit better. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, November 30, 2009 2:18 PM To: Tony Graziano Cc: [email protected] Subject: Re: [sipx-users] Best practices for a branch office 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/ _______________________________________________ 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/
