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/

Reply via email to