Yet another sizing/price advice question.This one with VPN's and T1's.

[ghurty]

I was asked to help size/price a new install.

The install will have about 300 users spread over three location linked by a VPN. There will be a maximum of 40 outgoing calls at a time (using a t1 connection), with a few more internal calls.

They want all the users to connect to the same server rather then having three servers linked together.

I have read the sizing page on voip-info and other posts here. But I am looking for some more advice based on past-experience.

Which version of Asterisk should I use?
What is a good server spec?
What is a good t1 card? Is it better to use a PCI card or a channel bank?
Anything special I need to be aware of regarding having so many users via a VPN?
What is considered a fair amount to help them install it?
Any other pointers?

Thanks

 

[wardmundy]

All your eggs in one basket. What could possibly go wrong?

 

[ghurty]

I agree. But even though I suggested it, I am being ignored.

What about the specs/version of asterisk?

Thanks

 

[reconwireless]

Ask questions... lots of questions. What type of voice trunks will you be using on this T1 sip trunks or PRI? What types of phones? What codec will you be using/ will the phones support?

If this is an existing business you need to determine the probable amount of internal calls and or call transfers between locations. This will help you determine if a vpn will handle the traffic. With just one server, transferring a call from office A, via office B to office C or interoffice calls bouncing around can add allot of additional bandwidth requirements real quick.

Based on the limited information provided I would push them hard for MPLS connectivity between the locations instead of vpn it will mean less hardware for you to sell them, but also puts the burden for connectivity and QOS back on the telecom carrier. MPLS with as strong of an SLA as you can squeeze out of the carrier would be my suggestion.

The amount of money they are going to spend on bandwidth to route their calls should make them reconsider getting three smaller servers instead of a larger central server.

You also will have some 911 routing considerations to make by pushing everything through one server, that is never fun.

 

[ghurty]

It will be a PRI.

They said external calls- max 40. Internal maybe about 20.

Lets assume I can get them to use a MPLS.

Now what?

Thanks

 

[Linetux]

"A" PRI? 24 channels? Or maybe you're talking more than that?

If they're coming over MPLS, you can probably have confidence in the quality of the calls, so long as you can do QoS for the rest of the network.

The real problem I have in this is emergency services. I refuse to setup systems like this when the client won't listen to experience and reason. I'll walk away because I know nothing good can come of a relationship like that.

If they're not going to put installs at each site, that means they won't have the ability to dial 911 locally - that's NOT a good thing, and could be illegal depending on your local laws. Many people don't even bother thinking about local OSHA codes in the US when spec'ing phone systems.

Generally speaking I still roll 1.4 for production. Maybe 1.6 if I have a specific reason for it.

But your version of asterisk is the least of your problems. Getting to know the client is problem #1. And with the questions you're asking, that's showing a lot of inexperience with phone systems... probably not a good combination.

All that being said, I'd go with Sangoma PCIe cards. If you need redundancy, I'd change my answer. Your server should probably say "SuperMicro" on it, but that's a generic answer to a question that needs a lot more information to qualify.

In short, you have a LOT of digging to do - not just on your client, but also on how you're going to pull this off.

I don't mean to pull this thread off-topic, but a lot of the negative "press" about Asterisk comes from folks that go in to something like this thinking it's dead-simple to take something as wonderful as Ward has given us and deploying it for a 300-seat office. Then stuff happens, there's no experience to back up how to fix it, the client gets pissed, and you lose the account. And you've now also turned a number of folks 'off' of Asterisk. It's not a good thing.

I'll get off my soapbox now.

 

[ghurty]

Sorry, I ment to say 2 PRI's.


They do want to have two servers for fail over/redundancy, so what would you suggest for the T1?

I agree fully regarding that they should have on in each location, however certain things I do not have control over.

I comments to them about 911 have fallen on dead ears.

The largest install I have done so far is a 100 user install, but that was in one location. They have been up and running for 5 months now without a single problem, and they were using SIP. And they did not require redundancy.

I am just trying to figure out how to properly set up redundancy if one system goes bad. How do I tell the phones to automatically roll over? Also what type of T1 card to use.

If it does end up on one system, what should the min. ram/cpu be on?
Is 1.6 more resource efficient?

I know, that I have never done such a large install, that is why I am looking for advice.

Thanks

 

[Linetux]

Three recommendations on the PRI, in order of preference for fail-over:

1) Red-Fone PhoneBridge. http://www.red-fone.com/ Their product uses TDMoE, which is a foreign concept to a lot of folks. Basically it puts the T1's over Ethernet, which then connect to your asterisk box. In the event of a fail-over, you signal the box the new MAC of the backup box, and your phones re-route. I know some BIG installs using this setup (like 4 E1's per server big) to great satisfaction for call centers.

2) Rhino's new failover setup - similar concept, but a different implementation. ( http://www.rhinoequipment.com/products/138 )

3) Xorcom's Astribank. Uses USB for failover. Requires Dhadi, so you might as well be on 1.6 for their stuff. My biggest problem with Xorcom is lack of hardware echo cancellation.

Now, actually DOING fail-over is a bigger issue. It depends on how far you want to go with it. My idea of fail-over is KISS: make it so that it's 90%, because the extra 10% is not only a lot more expensive, but a lot harder to implement - and only about .0002% chance you'll ever use it in normal operations.

The 90% solution is this: implement different T1's into different boxes, and use a 3rd server to actually register your phones. That way one PRI failing or one box failing won't affect much of anything.

As for the phones, you can do it the simple way - just register different extensions on different boxes... thereby still allowing for (at a minimum) outbound calling, and some form of ability to answer inbound calls. This is pretty simple to do, and will still probably never be used.

The next 'step' is to actually make backups of your main server every night (or every hour if you like) to a 'warm' backup server. Rsync the files over (a little tricky with mysql, but easily doable). In the event that something goes wrong, you'd have to change the IP on the warm server.

One up from that is actually doing some kind of heartbeat with Linux, so two boxes appear as one, but now you're dealing with mysql replication, which raises the bar substantially for most people. That, however, it your only true redundancy.

 

[Gibran27703]

So your PRI is limited to 23 channels for calls (23B+1D), you're already oversubscribing your link by 2:1.

As far as VPN goes, are the sites configured for full mesh VPN? What are the size of the Internet link at each site, and I assume these are used for both data and future voice correct?

How far are the sites from each other, are they in the same city or state, are they locations in the same provider's service area?

If you plan on researching MPLS (per the recommendation) above), verify the QoS SLA especially if you will be sending both data and voice on the same link. A lot of service providers will place you in specific queue (bulk) if you don't pay for voice queue (gold or what ever your provider calls it), so make sure you check on that.

No QoS you are in deep trouble depending on your connection and they shapers they use, small voice packets will be overtaking by bigger packets.

HTH,

Nabil

 

[blanchae]

You don't need to purchase Red-fone's TDMoE device if you are going directly between two Asterisk PBXs as TDMoE is already part of Dahdi's Dynamic Ethernet driver: dahdi_dynamic_eth

Here's a link that discusses how to setup TDMoE

On further reading, it seems that you are restricted to a direct connection between two Asterisk boxes or a dedicated network. Or in Redfone's case - direct connecting to their box. I understand that Digium stopped supporting TDMoE as it has timing issues.

 

[ghurty]

Is that only with asterisk 1.6 and higher?

What about processor/ram?

Thanks

 

[jmullinix]

I have read the thread and you are receiving good advice. Make sure you consider 911. If someone dies because an ambulance went to the wrong building, both that company and you will probably be sued. I never want to explain to a judge why 911 did not work.

I use a rule of thumb of 4 users per trunk. In your scenario, 300 users means roughly 75 trunks which is 3 or 4 pri's in the US and 3 E-1's in Europe. If is it a sales or medical organization, you will need more.

I would think that the customer would want a box at each location. That way, if the primary box or primary PRI goes down, the branches are still up. If the MPLS goes down, the branches stay up. In an installation this size, the cost of the server hardware is not that much. Put one at each location and use the VPN's to backhaul the necessary VOIP traffic and not all of it.

I have a buddy that maintains a campus with over 400 extensions. He has one server in each building for a total of 7 servers. His installation is rock solid. One machine does nothing but support the PRI (it is a K-12 school system, so one PRI is plenty) and routes calls to other servers based on the DID's.

You are an expert here, or you would not have "guru" after your handle. If this customer won't do this your way, walk away. The cost of the additional servers to do this right is minuscule when compared to the cost of the entire project.

 

[MrBostn]

Listen to the comments

They're right about 911. A business may not ever call 911, but that one time they do-It better work.

Also they may offer to sign something stating that they will not hold you responsible if something happens. Don't do that either.

In order of importance should be

1. 911
2. Almost everything else
3. Atersisk version

 

[Linetux]

I never had any issues when I used RedFone... aside from the fact that I was pushing my T1's over a 4-mile circuit, and once the latency hit above 5ms, the call quality went to crap... so it didn't fit my needs anymore and I pulled it out.

RedFone was one of the best fail-over devices when it came to semi-real redundancy. I know of no solution that will allow for calls to continue when you lose your PBX - something always breaks down at the carrier, SIP, etc. So make sure the expectations are where they need to be.

TDMoE works on Asterisk 1.4 and 1.6.

But if that scares you away, look at some of the other suggestions. That's why I gave so many... there's more than one way to skin this cat for sure.

As for the CPU, you could *probably* get by with an Intel Atom D510 honestly. But I wouldn't cut it that close... and you'd probably have to cut it slim with FOP and stuff.

But since you're talking about redundancy, I'm going to assume you want dual-power supplies, etc... so look at anything Supermicro with a Xeon processor. Of course you have to make sure you've got the right slots, etc. But honestly just about anything will be sufficient for this install - you're not doing anything crazy on this setup... just about anything from HP would work too (server-line wise) if you want 'real' support on the box. 2G of RAM is more than enough as well.

 

[ghurty]

Thank you everyone for all your help and guidelines. I will attempt to make another push to get them to see the proper way to do things.

I never had any issues when I used RedFone... aside from the fact that I was pushing my T1's over a 4-mile circuit, and once the latency hit above 5ms, the call quality went to crap

How were you connecting the T1's over a 4-mile circuit?

Thanks

 

[Linetux]

How were you connecting the T1's over a 4-mile circuit?

I guess you're not following what TDMoE is. It's basically taking a T1, and pushing it over ethernet. I have Metro-E connections, which allow me to push (L2) packets around as if they're connected locally. With Metro-E on a L2 handoff, distance isn't relative... however, latency is.


Let me take a snip from voip-info on the subject:

Once the TDMoE link is up, Asterisk just sees 24-lines that appear to be a T1 instead of having to deal with all of the complexities of VoIP. This is useful, since probably 75% of the utility of VoIP is really just the fact that it can run over a network. It's also handy because it unifies the flexibility and cost-savings of a Ethernet with the telephony-friendly aspects of a T1 (alarm codes, bundling trunks, channelization).

Note, however - this comes at a price. A single T1 will eat about 2M of bandwidth. Solid. All the time.

 

[ghurty]

I wasnt sure if I had it clear, but I think I do now.


One more question:

From what I can see, the redfone outputs it as a regular Ethernet which connects to the switch.

However looking at the rhino fail over card, it look like it it connects directly to the individual server. Is that correct? If yes, does it connect to a T1 card on the server, or to a second ethernet port.


Thanks

 

[Linetux]

These are the same concept, executed in two entirely different ways. Both, obviously, give you the ability to fail-over a T1 between 2 different Asterisk boxen.

The RedFone uses Ethernet as a delivery mechanism. You can connect them via a switch, hub, whatever. The only thing you have to do in the event of a failure is to change the MAC address the RedFone is 'sending' to. This is accomplished in a number of ways, but I won't go into details now.

The Rhino card is different. It uses a special driver to talk to its card. This card has a number of connections to it. One USB from one host, one from another (this provides power, even in the event of a failure of the first system). Two ethernet cables (you can switch ethernet or a T1 with this failover system) and the incoming T1.

I find the Rhino system a little kludgy... the first and second systems have to be within close proximity (due to the USB cables), and you still have to have a PRI card in each system (doubling your costs).