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.
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!
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.
viewtopic.php?f=9&t=7083&p=50481&hilit= ... f42#p50481
viewtopic.php?f=2&t=7601&p=53397&hilit= ... f42#p53397
And here is a wiki article explaining Differentiated services: http://en.wikipedia.org/wiki/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: http://www.hottrainingmaterials.com/fre ... -model.php