RV082 Properly Setting QoS or Bandwidth Profile for VoIP
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.
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?
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.
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:
Identify ALL TCP/UDP ports required for your SIP provider
Set a manual IP for said device, if possible.
Establish QoS rules for BOTH Downstream/Upstream ports as specified in step 1
If using more than 1 SIP device, setup port triggers for the ports specified in step 1 (does NOT require static device IP)
If using only 1 SIP device, setup port forwards for the ports specified in step 1 (requires static device IP)
For choppy voice/disconnect/echo issues,
DISABLE ALL ALG options (I don't recall if this is even available in the RV082, but most routers have this option)
Disable SPI Firewall (generally not needed unless you are an Enterprise user)
OK to enable base firewall (this is kind of the bare minimum anyone should always keep)
Set SIP device as DMZ host in RV082 settings
Do NOT use bandwidth control, just use QoS
DISABLE uPnP - this messes with the port triggering rules causing calls to randomly be dropped as soon as you pickup
There are certain SIP handshake ports that should NOT be specified to port forward or port trigger because many auto-dialer systems try to dial these ports in, creating these "ghost ring" problems where the SIP device will just ring off the hook from unknown extensions/numbers. The only ports that should be forwarded or triggered are those required for actual voice data.
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...