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.
#96746 by coastalcruiser
Wed Jun 06, 2012 3:08 am
Here is an example of some router documentation for a Sonic Wall Appliance that supports my train of thought. I don't know how this info fits in with ibmofo's approach to enabling QoS, but it does lend some support to the idea that the device in question (in this case the ooma telo) must support 802.1p (and thus VLAN tagging) in order to implement QoS (at least one "brand" of QoS).

Excerpt from ( ... g/qos.html)

Enabling 802.1p marking allows the target interface to recognize incoming 802.1p tags generated by 802.1p capable network devices, and will also allow the target interface to generate 802.1p tags, as controlled by Access Rules. Frames that have 802.1p tags inserted by GMS will bear VLAN ID 0.

802.1p tags will only be inserted according to access rules, so enabling 802.1p marking on an interface will not, at its default setting, disrupt communications with 802.1p-incapable devices.

802.1p requires the specific support by the networking devices with which you wish to use this method of prioritization. Many voice and video over IP devices provide support for 802.1p, but the feature must be enabled. Check your equipment's documentation for information on 802.1p support if you are unsure. Similarly, many server and host network cards (NICs) have the ability to support 802.1p, but the feature is usually disabled by default.

I have a netgear switch not a sonicwall, but this seems to be generic guidance. I will of course do some real world testing at some point with various configs, but being a [semi-retired] network engineer and networking instructor, I have some drive to try and actually understand the underpinnings of what's going on here.

ibmofo: If you have the time/interest to reply.... I looked up the router you indicated that did MAC based QoS. I see it supports VLANs. Do you happen to recall configuring VLAN support when you got QoS working, or did you simply enable a seeting for MAC based QoS?
#96747 by coastalcruiser
Wed Jun 06, 2012 3:34 am
Cyberchat wrote:I believe that the discussions in this thread have some "apple and oranges" types of discussions going on in terms of QoS (Quality of Service). From my perspective, QoS as it relates to the OOMA Telo's implementation is different than the 802.1p PCP (Priority Code Point) field in the packet header which as we discussed earlier is applicable to only VLAN based (logical) networks. There isn't anything apparent in the OOMA Telo documentation or User Intefaces which suggests that the Telo is VLAN-aware.


So, in summary, I believe that although the Telo's QoS and the VLAN's PCP-badsed QoS are targeted toward the priortization of data packets to provide consistent data packet delivery Quality, I see no evidence that these two QoS functionalities can plug-and-play together. There is no evidence that the Telo is VLAN-aware. If the Telo is not VLAN-aware, then the 802.1p PCP (Priority Code Point) field would not be in the Telo's vocabulary.

Note: I made my last post before noticing you had posted this. Did not get an email notification for some reason.

Thank you kindly for that reasoned response. If I had to bet a nickel at this point I would side with your logic and conclusion. This would explain the dearth of references to "ooma telo + 802.1p". My only point of departure would be that with VLAN capable routers/switches having entered the consumer price realm, enabling the 802.1p protocol (and thus VLAN tagging) on gear such as ooma may not be such a bad idea. In other words I am not seeing where implementing this would only be appropriate to large scale networks.

In any case, assuming that the ooma telo does not implement VLAN tagging, I would assume that I must implement QoS via configuring port priority (the only other option on my shiny new netgear ProSafe GS-116 switch). This a less flexible method, but is certainly workable in my application.

I am left however, wondering about ibmofo's Linksys WRT310N being able to implement QoS by MAC address. That is not an option on my GS-116, nor is prioritizing by IP address, which ibmofo also alluded to. The latter method is easy to understand, but in terms of prioritizing by MAC address, I am left still wondering -given the presumption of no VLAN support on the telo- what is the Linksys WRT310N keying on in the packet to determine how to prioritize it? That of course is also presuming that imbofo experienced an improvment in call quality upon enabling the feature.. which would infer that packet prioritization is indeed occuring within that router.

#96748 by coastalcruiser
Wed Jun 06, 2012 3:52 am
coastalcruiser wrote:I am left however, wondering about ibmofo's Linksys WRT310N being able to implement QoS by MAC address.

Aha. I see said the blind man. I looked up the user guide for this router. I was infering that the MAC prioritization spoken of was frame based (i.e. Examining the Layer 2 MAC (Ethernet) frame). But according to the user guide, QoS is implemented by simply typing in the MAC address of the device (in this case the ooma telo) and manually assigning a priority (Choices: High, medium, normal, low). I am assuming then that is what you did ibmofo, if you're there. You added the MAC address of your ooma gear into the Qos setup on your Linksys, correct?

That makes sense now.

OK. So my dream of being able to apply QoS purely based on packet examination is fading. No worries. Going to Pan B on my network architecture. :cool:
#96789 by coastalcruiser
Wed Jun 06, 2012 8:46 pm
Yes: ooma does support QoS at the packet level. But not with 802.1p.

OK. I found what I was looking for, but it wasn't where I first looked. :shock:

At this point it seems pretty clear that ooma does not support the 802.1p protocol, which would identify and prioritize voice calls on a network based upon examining packets. However, I am learning that QoS is implemented in two very different ways on networks; with the 802.1p protocol, which ooma does not appear to support... and with a technique known as Differentiated services, which ooma does appear to support.

A quick backgrounder is needed to explain this in case you don't do networks for a living. As mentioned earlier in the thread though, this information has no revelance for anyone configured as Modem-->OomaTelo-->Router. And even if you are configured Modem-->Router-->OomaTelo this information only has a bearing in certain circumstances (example to follow).

The 802.1p protocol (a function of the 802.1Q protocol for VLANs) has revelance to a portion of a network packet known as the Data Link Layer, abbreviated 'Layer 2'. Packets are distinguished here by their MAC address (Media Access Control Address), which is a unique 12 digit number in hexadecinal format (i.e. 12-3E-29-21-B6-57). QoS can be implemented at the packet level in the header of this section of the packet via 802.1p. However, the Data Link portion of the packet (also referred to as the Frame or Ethernet Frame), is applicable only for the local network (like a home network). The frame and all its data are discarded when the packet is forwarded to another network (such as the biggest network of all, the Internet). Therefore any QoS information tied to the packet is lost when the packet leaves the network. This is a fine technique as far as it goes (so to speak) as voip packets are shoved into the Internet router ahead of all others.

So it makes sense that packet based QoS would also be implemented in such a way as to be retained as the voip packets traversed various networks on the way to their destination. This way an IP phone call could theoretically be guaranteed prioritization along the entire path of the call. In this case QoS has been implemented in a section of the packet known as the Network Layer, or Layer 3. There are several relevent terms to describe this function, but it is generally known as Differentiated services or DiffServ. Diffserve reserves a section in the IP Header of the packet called the DSCP field for storing priority information about the packet. The IP Header is where the IP address is stored, and, unlike the Data Link section, this portion of the packet is retained for the entire trip to its destination (although the IP address itself may change). So, DiffServ worls both within the local network as well as across networks. And ooma apparently supports the use of the DSCP field! :D

I found the following two forum links to support this idea, where a couple of folks "sniffed" a packet to see what ooma was adding. The DSCP field needs to contain a hexadecinal value of "EF" (46 in decimal) to be identified as a voice packet.



And here is a wiki article explaining Differentiated services:

So, when would one care about all this packet based QoS wonderfullness? Let me give you my scenario as an example. Keep in mind that to achieve the best call quality it helps to have every segment or hop of the network be aware of which packets are voip packets.

In my situation I am trying to install 10 ooma telos in 10 adjacent apartments (although for the purpose of this example it could be just one telo). Now if the router/modem connecting to the Internet was local to the apartments I could simply install a QoS aware switch. The telo(s) could plug into a port or ports on the switch designated as high priority, and a wireless router for general Internet access could be plugged into a different port flagged for normal priority. Or if the switch instead allowed for QoS based on the IP address or MAC addres of the telo(s) you could program the info for each telo into the switch and achieve the same result. I am learning that the method varies according to the brand/model of the switch. My new Netgear Prosafe GS-116 allows port-based prioritization (and 802.1p packet based prioritization, which we've learned is not supported by ooma), whereas ibmofo's aforementined Linksys WRT310N allows prioritizing packets from specific devices by their IP or MAC address. Depends on the switch (which is a Layer 2 device, by the way).

Anyway, in my case the Internet router/modem is a distance of 500 feet away from the apartments. There is a pre-existing wireless access point to connect the residents to the Internet connection. I now want to route the ooma traffic across the same wireless link. Why set up a separate wireless link just for ooma calls link if the existing link can handle the traffic? And indeed, the existing link has plenty of capacity to handle the traffic, but that traffic MUST BE PRIORITIZED. The fact that each resident makes a direct wireless connection to the AP eliminates the possibility of using a QoS switch at the apartment building. When another wireless connection is made to route telo voip packets across the link, the voip packets will compete for bandwidth against existing network traffic.

This is where Differentiated services and the DSCP field comes in. The wireless access point is a Ubiquiti brand 'Picostation'. When I looked up how these devices implement QoS it turns out they examine the DSCP field of the packet. That is perfect, because since the telos set the value of this field to "EF" the wireless link automatically knows to give those packets priority over others as they traverse the link.

These types of APs work at Layer 3, the network layer. They have no mechanism for QoS implemented at Layer 2 (i.e. MAC based prioritization). And since the Picostations are designed to work automatically with any QoS device that supports Differentiated services, they skip over the idea of programming in specific IP addresses for specific QoS equipment. Using the DSCP field is a simple, clean way to get the job done. Automatically.

And this is the solution I was looking for when I started down the 802.1p path; a way to automatically prioritize voip calls across a variety of networking topologies.

That's how it all looks on the chalkboard anyway. For completeness I will post the final results in this thread when the project is finished.


ps - For anyone wishing to learn [more than you ever wanted to know] about the network model that explains layer 2, layer 3, and all that jazz can click this link: ... -model.php
#96814 by abqbill
Fri Jun 08, 2012 12:50 pm
All good info, except from the Wikipedia information and the RFC, it appears that EF is an abbreviation for "expedited forwarding," rather than the recommended hexadecimal code. 46 in hex is 2E (binary 101110), not EF. (EF is decimal 239.)

#96821 by coastalcruiser
Fri Jun 08, 2012 4:19 pm
abqbill wrote:All good info, except from the Wikipedia information and the RFC, it appears that EF is an abbreviation for "expedited forwarding," rather than the recommended hexadecimal code. 46 in hex is 2E (binary 101110), not EF. (EF is decimal 239.)


Thanx for the correction. I wrote down the "46" quote from a forum thread. Always pays to check your sources.

The official response to my inquiry just arrived from ooma tech support:

"Dear Jim,

This is in regards to your question regarding if ooma telo is designed to support IEEE 802.1p
Unfortunately, the machine uses DiffServ/TOS for QoS.

Currently not supported."

Who is online

Users browsing this forum: No registered users and 15 guests