This forum includes tips for maintaining the best audio quality possible with the Ooma System. If your Ooma system is having issues with dropped calls, static audio or echo, look here for assistance.
#579 by dirkhh
Fri Sep 12, 2008 2:14 pm
I think many people with a somewhat more sophisticated network setup don't really want to (or as in my case, cannot) put the ooma box between the DSL modem (Cable modem, etc) and their internal router.

Do you have some guidance for how we should setup QoS on the router to ensure the best possible quality for ooma phone calls?

Reading through other threads right I decided to implement highest priority traffic of up to 160kbps reserved in both directions. Is that the setup that you'd recommend?
#580 by trim81
Fri Sep 12, 2008 3:10 pm
dirkhh wrote:I think many people with a somewhat more sophisticated network setup don't really want to (or as in my case, cannot) put the ooma box between the DSL modem (Cable modem, etc) and their internal router.

Do you have some guidance for how we should setup QoS on the router to ensure the best possible quality for ooma phone calls?

Reading through other threads right I decided to implement highest priority traffic of up to 160kbps reserved in both directions. Is that the setup that you'd recommend?


There is really no magic number for QOS.. you have to test it yourself and see
#697 by routerspecialist
Tue Oct 07, 2008 6:19 am
I disagree. There are standard rules for QoS, and if you have the correct router they are relatively easy to implement.

But we need detail from Ooma about what ports are used for call setup and call control, and also call payload, both outbound and inbound. I've tried and while Ooma has given me some information, it's not detailed enough to successfully program QoS. Call setup and control must priortized at high priority, as in TOS bit 5 or DSCP at EF, while payload data a step lower. But you need to know the correct ports to accomplish this, and which are UDP and which are TCP ports and what each port is used for, call setup/control or call payload.

It's also very important to have a router that will allow you select and apply QoS to the correct interface. You need to be able to select the WAN interface and apply QoS there both inbound and outbound. Inbound (from the big I), you need to apply policing. Outbound you need to apply what Cisco calls "fancy queuing" or CBWFQ. Most of the smaller routers from Dlink, Linksys, etc don't have these kinds of flexibilities, if they support QoS at all.

If you do can do all this, QoS will work. I know, because I've done it, on a professional level. I also will acknowledge that this is not for the average user. And furthermore, you need a router that will have a good flexible QoS scheme.
#702 by Bobby B
Tue Oct 07, 2008 5:26 pm
In my testing ooma QoS works great without any external QoS routers.

If you have an advanced network config, you may wish to configure QoS on your router (if supported). To setup QoS on a Cisco router for ooma VoIP traffic or any other application traffic you wish to prioritize, all you need are the ooma service ports used (as trim81 pointed out above). The easiest way to set this up is to use a low latency queue (LLQ) which will prioritize matched packets over other packets.

Check out this Cisco Document for some sample configurations (you'd need to modify access-list 110 to match on port numbers). If you need an example with ooma-specific ports, let me know and I can post it here.

routerspecialist wrote:But we need detail from Ooma about what ports are used for call setup and call control, and also call payload, both outbound and inbound. I've tried and while Ooma has given me some information, it's not detailed enough to successfully program QoS. Call setup and control must priortized at high priority, as in TOS bit 5 or DSCP at EF, while payload data a step lower. But you need to know the correct ports to accomplish this, and which are UDP and which are TCP ports and what each port is used for, call setup/control or call payload.

It's also very important to have a router that will allow you select and apply QoS to the correct interface. You need to be able to select the WAN interface and apply QoS there both inbound and outbound. Inbound (from the big I), you need to apply policing. Outbound you need to apply what Cisco calls "fancy queuing" or CBWFQ. Most of the smaller routers from Dlink, Linksys, etc don't have these kinds of flexibilities, if they support QoS at all.
#1211 by rthomas
Mon Dec 15, 2008 10:07 am
You said... "If you need an example with ooma-specific ports, let me know and I can post it here."

Yes -- please do. Thanks in advance.

Ryan
#1217 by Dennis P
Mon Dec 15, 2008 1:53 pm
routerspecialist, all call control, signaling and node management information are tunneled through a VPN to our data center. This VPN uses UDP port 1194. If you want to setup your own QoS, this port should be the highest priority, followed by the RTP stream itself which uses the UDP port range of 49000-50000.

#2534 by routerspecialist
Mon Feb 02, 2009 11:14 am
But what most non-professional folks often miss (fully understandable as they don't do this for a living) is the INBOUND direction.

QoS outbound is NOT ENOUGH.

So, this is my SIXTH attempt to get an answer to this question: Inbound, are the ports the same? 1194 for call control and 49000-50000 payload inbound as well?

You imply that 1194 is a vpn. VPN implies to me some kind of encryption and authentication. So is it a tunnel? IPsec? How do I identify and differentiate the traffic inbound? In cisco terms, ESP and AH use IP protocol 50 and 51 to communicate, not ports.

On the INBOUND, I need to identify ooma traffic coming IN, call setup and payload.

Re:

#2536 by Bobby B
Mon Feb 02, 2009 12:04 pm
Hi routerspecialist, please see inline.

Thanks,
Bobby

routerspecialist wrote:But what most non-professional folks often miss (fully understandable as they don't do this for a living) is the INBOUND direction.

QoS outbound is NOT ENOUGH.


In most setups, QoS in the inbound direction is not required for VoIP, since most computer and home networks speeds are greater than the speed of your Internet service provider (in the downstream direction). This is why QoS on the Hub is disabled by default in the downstream direction.

routerspecialist wrote:But what most non-professional folks often miss (fully understandable as they don't do this for a living) is the INBOUND direction.
So, this is my SIXTH attempt to get an answer to this question: Inbound, are the ports the same? 1194 for call control and 49000-50000 payload inbound as well?


Can't you just match on the source port? For example, if ooma connects using a destination port of 1194, then the return traffic would have a source port of 1194. E.g your QoS access-list would be (using cisco syntax):

access-list 101 permit udp any eq 1194 host <your host>

Also, I believe the same source and destination ports are used with our traffic (e.g. 1194 is both the source and destination port).

routerspecialist wrote:You imply that 1194 is a vpn. VPN implies to me some kind of encryption and authentication. So is it a tunnel? IPsec? How do I identify and differentiate the traffic inbound? In cisco terms, ESP and AH use IP protocol 50 and 51 to communicate, not ports.


VPN traffic is encapsulated in UDP 1194. This is how everyone else tunnels ESP and AH traffic through NAT (though perhaps on different UDP port) and other networking environments.

Who is online

Users browsing this forum: No registered users and 5 guests