07-03-2013 04:53 PM
We have been running a Cisco RV082 revision 3 router for several months now and have been trying to figure out how to properly setup QoS or bandwidth profile for VoIP on a shared 16x3Mb line. I'm trying to get my head around the appropriate behavior and circumstances for QoS to work properly. However, in both instances, I had the same problem.
Setup:
2: 8x8 VoIP Phones (polycom 331 both with static IP's)
Single subnet, all devices directly connected to router
Scenario 1: Enable QoS for VoIP ports
Anytime a user consumed near the maximum available bandwidth, QoS did not prioritize VoIP packets and I completely lost functionality of VoIP - no incoming or outgoing calls. Incoming calls would ring once, hang up, then ring again, hangup, until a connection was re-established with the VoIP server, and then stop ringing and hanging up.
Scenario 2: Setup bandwidth profile with reasonable floor limits for VoIP and other services. Set maximum bandwidth available to be equal to our 16Mb line. I thought this would also throttle back connections when VoIP was trying to make a connection, but the same behavior. When any user began consuming near all the bandwidth, outgoing calls would fail and any incoming calls would ring once, hang up, then be stuck in a loop where the same number would ring, hang up, ring, hangup. Once bandwidth came back, the incessant ringing turns off.
Scenario 3: Setup bandwidth profile with reasonable floor limits and now, very low upper limits. So even if all users were downloading some huge file, the combined bandwidth used always leaves 384Kbps available for VoIP both up and downstream. This works perfectly.
So conceptually, I was under the assumption that QoS would automatically kick in, throttling users maxing out bandwidth allowing VoIP traffic. This does not appear to work in our setup. And with a bandwidth profile, I was under the assumption that setting a bandwidth floor would have the same effect. However, this does not work. We are currently using scenario 3, which works fine, but it means no single user can ever use 16Mb available. Is there something I'm missing in my understanding of how QoS works for this device and/or how a bandwidth profile floor and ceiling are configured?
Thanks in advance for your insight!
04-27-2015 08:31 PM
On the rv082 v3 I have it doesn't seem like high priority works nor does rate control. I am using this for VOIP for a single phone. When downloading a file of any significance the phone gets all choppy and I know I have the priority set right for SIP signaling (5060-5070) and RTP (10000-20000). The phone also is choppy when setting it using rate control. I have a dsl connection (4mb/512kb) and with rate control I set the minimum for SIP and RTP to 80kbps and maximum 90kbps in both directions (Up/Down). Still, the phone is choppy. How did you setup scenario 3? Any help is much appreciated.
10-11-2015 02:12 PM
We lost our account access to the OP and are re-posting under this new account ... but here goes!
This is a very late reply but maybe someone can find this at least somewhat useful. Under 8x8 technical spec, and perhaps even under general SIP spec, the RV082 is absolutely unsupported due to whatever limitations there are on the hardware itself. Even with the latest firmware, dated July 2015, and the availability of port triggering, the service is not 100% reliable. First off, best practices:
With the above, we have been able to maintain adequate use of both our 8x8 lines and an additional Vonage line. However, the port triggers/forwards are not perfect and we have some issue with our back office line where calls get randomly dropped when transferring calls in. Because that specific line does not require any advanced features of cloud based calling, we might drop it entirely and convert it back to landline. We only need the cloud features for our main line, which works perfectly for all incoming calls.
Anyway, there is still very little documentation related to the RV082 running 8x8 ... this post seems to be the first thing that pops up on Google searches. Maybe a DD-WRT/OpenWRT solution in the near future may be more appropriate where an enterprise router may be cost prohibitive or a router behind router technically troublesome to setup.
04-27-2015 08:32 PM
duplicate
04-27-2015 08:33 PM
duplicate
04-27-2015 08:33 PM
duplicate
04-27-2015 08:34 PM
duplicate
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide