3cx with TWBC bandwidth

[tex834]

I am planning to install 3cx (16 calls) on Win 7 64bit PC (core i7 8GB ram) with Time Warner Business Cable 15mbps x 2mbps. There will probably be around 5 to 10 simultaneous calls by the users with no outside extension, softphones or my3cx phones. There will be 12 VOIP Yealink T38G phones with Nexvortex VOIP provider. There are 12 Windows workstations with standard internet data usage (browsing, email, etc). The phones will connect to 100MB switch and pigtail to the workstations. The firewall is Dell Sonicwall TZ215W.

Will this environment be ok for bandwidth and call quality?

 

[cobaltit]

@tex834

Couple of things.

First, Sonicwalls are known not to play nice with VoIP. I've always replaced or bypassed them myself based on other's experience with them. I would reference this article and do some searching on the forums:

http://www.3cx.com/blog/voip-howto/sonicwall-firewall-configuration/

On paper, you have enough bandwidth, but keep in mind that all cable internet providers I know claimed speeds are 'up to' the purchased speed, not guaranteed. So you would definitely want to set your QoS to something conservative like 12mbps down and 1.5mbps up giving priority to your VoIP traffic. After running that way for a week or two, you can start adjusting higher if there are no issues. The other option is to make G.729 the default codec with Nexvortex, but keep in mind a 16SC license only comes with 8 G.729 licenses. For the sake of being thorough if you go the G.729 route I would also change the code priority on the phones, although that box as spec'd has more than enough HP to handle the transcoding.

Good luck!

 

[jpillow]

I dont think if you have a bandwith issue with will be due to the amount of bandwidth at your location but, jitter, latency, etc... TWBC offers no SLA meaning best effort service, so youre basicallly rolling the dice. I'd go either one of two routes to ensure later issues avoided, if your dead set to go with an ITSP I'd get a T1 for the voice traffice and TWBC for data anwill avd use a load balancing router to route traffic. Or simply use Analog lines by doing so you will make your life easier and the clients experience much better. As for as the OS, router, hardward you are good to go, I've a few locations using Sonicwalls and havent experienced many issues at all../ Good luck

 

[lneblett]

I have the same setup (10/2) and use TWC in a number of other locations. The question is really about the usage as cobaltit points out, for voice only, you should be fine...........if that is all or the vast majority of the traffic. The CPU running the system is way more than needed, so no problems there.

If there is data traffic, which certainly there is, it will mostly depend on how much at anyone given point in time, will it also be at a time of peak voice traffic, and will it involve any significant upload bandwidth as that is where your bottleneck is. TWBC does claim to use some QOS for their business class customers, and they definitely have the capability to do so. Whether they invoke the settings in your area may be a different question and if they do, they only do for all business data and only against their residential services. Nevertheless, QOS can only do so much and if the demand exceeds supply, then you likely will have issues.

In addition to JPillow's (JP) suggestion, you might try and find a provider that offers symmetrical bandwidth. TWC typically assumes businesses will have more need for download data and sells accordingly. In most scenarios the download need is true, but doesn't really serve those wanting to go VoIp/SIP and/or who may wish to host their own services. They (TWC or others) may have other packages more suitable for your need.

While JP's suggestions are the more bullet proof, they also tend to be the more costly as you now have to introduce added hardware to support the analog lines and the added subscription costs...all being incremental to the costs already subscribed to with TWC. Of course, TWC could have a different price scale that essentially imposes a significant price increase if upload speed is added. I have to assume they know this and use to their advantage.

You also need to ensure that if the client has any batch jobs that require internet, say Carbonite or other back-up to cloud, etc., that these be done off-hours.

 

[tex834]

Thanks everyone for the replies. I will keep this in mind.

@cobaltit (or anyone), how can the QoS be set to 12mbps down and 1.5mbps up? What are the instructions for this? Thanks

 

[craigreilly]

cobaltit,
What kind of issues with SonicWalls? I have had a system up for a year using a SonicWall with a NexVortex circuit. About 1 time per month I get an email that the link was down for about 60 seconds and it is usually the System Admin recycling the router because of DHCP issues.
The only thing I can not get going at the moment is inbound fax's to the build in 3cxFaxService.

 

[ian.watts]

You'll want to get good numbers on speed tests.. preferably after hours.. or you can go with the expected rates you are subscribed for.. not your provisioned numbers (they tend to overprovision..).

From there, you will want to enable Bandwidth Management on the WAN interface, and plunk in those values for ingress (down) and egress (up) there.

You will then want to shape it using Access Rules for your RTP traffic primarily.. SIP is control and isn't all that tricky.. but maintaining those audio streams is critical.

Though you can clump services and addresses together.. you will want to explicitly reserve some bandwidth for both WAN -> LAN for RTP as well as LAN -> WAN for RTP.

If you think you've got it.. a speed test will usually "put it to the test" if you will.. and a current external call will either choke on the audio stream based on whether the test is on download or upload.

Spent the better part of an evening troubleshooting it for a remote office in San Francisco.. with some of the suckiest connectivity ever. Not the "Bay Area".. but the city proper. When I got their 2048/512Kbps DSL circuit configured through a TZ210 with this stuff, the data throughput choked a bit.. but audio finally worked both ways!

 

[tex834]

cobaltit/ian.watts,

I am not quit clear as to where the QoS is configured. Inside the firewall, Windows OS or 3cx console?

And just to clarify, when establishing QoS in this scenario, does this dedicate 12x1.5 to Voip and 3x.5 to data?

I see that Ian.watts has giving QoS instruction for the firewall. I have also seen discussion about Windows OS relating to QoS. http://www.3cx.com/blog/voip-howto/qos-windows-2008-server-local-policy/ So, should this also be setup?

Are there any QoS setting inside 3cx console?

 

[jpillow]

QoS is handled in the router in most cases your router can detect voip traffic and automaticall give it proority. Your Sonicwallhas those capabilites.

 

[cobaltit]

cobaltit,
What kind of issues with SonicWalls? I have had a system up for a year using a SonicWall with a NexVortex circuit. About 1 time per month I get an email that the link was down for about 60 seconds and it is usually the System Admin recycling the router because of DHCP issues.
The only thing I can not get going at the moment is inbound fax's to the build in 3cxFaxService.

@craigreilly

Not from personal experience, as I just don't touch the Sonicwalls period. But Kevin@3CX doesn't really like them, and the 3CX training videos mention they are known not to play nice with SIP. Now this could be earlier models/firmware or something along those lines, but there are several threads about them not working quite right. I imagine veterans would be able to figure it out without problems, but beginners might want to keep all their hair

 

[ian.watts]

It is indeed not for the faint of heart.. that being SonicWall traffic shaping for RTP.

QoS in general won't help unless your LAN is congested.. which my largest clients may have some link aggregation between switches to relieve such congestion anyway.

Most ISPs won't do QoS with you anyway. We have gone with some ISPs who provide SIP trunking services and have had relative success.. at least with browbeating them for any WAN traffic contention since they are delivering it.

Our standards include a dedicated IP, a non-SonicWall NAT router (we go with a NetGear model..), and "not" Comcast or a provider with high jitter after measuring for jitter.

While we can succeed with a SonicWall on Comcast with a single IP just fine.. too many problems with other sites.
It's like the whole T38 fax option. Sure, I got it to work between an MFP from one client to send/receive fax to the 3CX Fax service or a fax connected via ATA.. but otherwise was inconsistent or the handshakes would fail (I could hear the attempt at the far end.. oh, the sysop days of BBS..).

We developed those standards based on painful experience.. BEFORE that training conference up at Redmond in May. Wasn't a surprise to hear SonicWall was.. not recommended.. yeah, let's put it that way.

Why the dedi? We still have SonicWalls with VPN licenses for our non-SBS or Mac clients.. so we have two routers on site (not the ideal topology, I know..).
I found two years ago after an associate left me holding the bag with a 3CX site which audio was one way.. inconsistently. Though the access rules and NAT policies called out the RTP ports for both inbound and outbound NAT.. the SonicWall decided to utilize those ports on the WAN regardless.. which killed the inbound audio. After I set those rules/policies to translate on a different WAN IP, their problems disappeared. That started the "dedicated IP" requirement.

Another client had the "dedicated IP" but audio quality would suffer. With some of the UTM features enabled, two site-to-site VPNs, with client IKE and SSL VPNs, and finally with the WLAN option built in (TZ200W..), we monitored and saw the processor utilization peg at times and concluded the appliance could not keep up at all times.. which is when the call audio suffered.

So, yes.. it can be done. It is a bit of a process to step through, however. Indeed, I would suggest a dedicated NAT router and a dedicated IP on your circuit. I would run some jitter tests against the circuit, though, to make sure the circuit is suitable for VoIP at all to begin with.. first. For some, we've gone with the cheap DSL option. Makes for a PSTN line for fax, too!