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.
#96707 by coastalcruiser
Mon Jun 04, 2012 5:40 pm
I am fairly new to ooma and have been posting mainly to this thread (viewtopic.php?f=2&t=13691) in the installation forum. This new question seems to deserve a thread of its own though, and the Call Quality forum is more appropriate for it as well.

The question is, does ooma support the 802.1p protocol for managing call quality on a network? Under certain conditions support of this oddly named protocol could be of great benefit to ooma subscribers. Yet, after doing a google search, searching these forums, emailing ooma support, chating with ooma support, and finally calling ooma support... I am forced to conclude that the answer to this [seemingly innocent] question does not exist in this space/time continuum.

For anyone wondering, here is an example of when support of 802.1p would be of importance; The "p" in 802.1p ostensibly stands for "priority". It's a method of giving certain network packets a higher priority over other packets. All the 802.1p protocol does is add a small number (0-7) to each packet generated by a device on the network which tells the networking equipment what priority to give the packet. Comes in handy for time sensitive applications such as making telephone calls over the Internet.

If you plug your telo into you Internet connection and then plug your router or switch into your telo, the 802.1p protocol has little meaning to you. In that case the telo does all the work for prioritizing calls, and who cares how it does it, as long as it works, right?

However, if you instead plug your router into your Internet connection and your ooma telo into a port on your router (or switch), 802.1p would seem to be of some importance. In that case the prioritization of one packet over another is handled by the router/switch, rather than the telo. And the 802.1p protocol is one of two ways the router/switch can be programmed to prioritize calls. If ooma supports 802.1p (by adding that aforementioned number to its packets) then you can simply program your QoS router/switch to pay attention to packets arriving at any of its ports and give them priority based upon the number in the packet (0-7). The other of the two methods to program your QoS router/switch is to give one port priority over another port. In this latter case one would plug their time sensitive devices/applications like your telo into one particular port that has been programmed as a "high priority" port.

Theoretically either method can achieve the same results, but being able to prioritize packets (regardless of which port they come in on) seems far more flexible than prioritizing ports ... if you see my meaning.

I assume of course that even though the question of whether ooma supports 802.1p or not may have gone unanswered to this point, it has not prevented the many folks who setup their telo as INTERNET - ROUTER - TELO from achieving good call quality. And such folks may be thinking "Hey coastal... get over it". And indeed I could get over it and just use port priority setting on my new switch. But then again it does seem kind of silly that the knowledge of whether ooma supports 802.1p lies only with the high priests of telephony.

So I am going to shake the ooma tree of knowledge a bit longer to see what shakes out, and will post my results to this thread. A level 3 support person at ooma has promised to check with the "engineers" and contact me with the results. I am also trying to capture some packets with Wireshark to see for myself if the telo is adding the 802.1p data to its packets. That is taking some time though.

cheers
jim
#96732 by Cyberchat
Tue Jun 05, 2012 4:27 pm
Jim,

Welcome back to the forum!

I believe the PCP (Priority Code Point) field you are referring to is applicable to only VLAN based networks. Check out the following two links within the Wikipedia.org site:

IEEE P802.1p
http://en.wikipedia.org/wiki/IEEE_P802.1p

"The QoS technique developed by the working group, also known as class of service (CoS), is a 3-bit field called the Priority Code Point (PCP) within an Ethernet frame header when using VLAN tagged frames as defined by IEEE 802.1Q. It specifies a priority value of between 0 and 7 inclusive that can be used by QoS disciplines to differentiate traffic. Although this technique is commonly referred to as IEEE 802.1p, there is no standard or amendment by that name published by the IEEE. Rather the technique is incorporated into IEEE 802.1Q standard which specifies the tag inserted into an Ethernet frame."

... And ...

IEEE 802.1Q:
http://en.wikipedia.org/wiki/IEEE_802.1Q
#96734 by coastalcruiser
Tue Jun 05, 2012 4:40 pm
Cyberchat wrote:I believe the PCP (Priority Code Point) field you are referring to is applicable to only VLAN based networks. Check out the following two links within the Wikipedia.org site:


Howdy. Right you are. I too discovered that too (same wiki article) while researching 802.1p. I left the vlan info out of my post for simplicity. That Netgear switch does support vlans. Parenthetically, I am in a separate conversation with them to learn more than the manual tells about how much vlan configuration must be done in order to enjoy 802.1p. The config utility allows you to activate 802.1p support, and doesn't make a peep about needing to enable vlan support. So I don't know if it is latently activating vlan support when you enable 802.1p, or if their is basic global vlan support on by default.

I figure I will first find out if ooma sets that 3 bit CoS field, then tackle getting the switch to pay attention to it.

jim
#96736 by lbmofo
Tue Jun 05, 2012 4:54 pm
Maybe I am just confused but are we not all using this protocol whenever we use QoS by MAC in our routers or switches? I think once you set the priority level, the router/switch has to worry about what MAC address got what priority and not for the individual devices to worry about. In my thinking individual devices doesn't have a say in this priority field (other than possibly router/switch telling the devices what to populate in the field as a "nice to have" when communicating back).
#96737 by coastalcruiser
Tue Jun 05, 2012 5:14 pm
lbmofo wrote:Maybe I am just confused but are we not all using this protocol whenever we use QoS by MAC in our routers or switches? I think once you set the priority level, the router/switch has to worry about what MAC address got what priority and not for the individual devices to worry about. In my thinking individual devices doesn't have a say in this priority field (other than possibly router/switch telling the devices what to populate in the field as a "nice to have" when communicating back).


I think what you are saying is only true when PORT based QoS is in effect. With port based QoS you configure one or more ports to have priority. In that case the ROUTER/SWITCH is in control, and individual packets are not examined. ALL packet on a particular port are given priority (or not) over ALL packets on other ports.

But in your reference to "the router/switch has to worry about what MAC address got what priority", when speaking about a particular MAC address -and by inference its associated packet- that is PACKET prioritization, and in that case the router/switch needs a hint as to how to prioritize the packet. The "hint" is the data carried in the CoS field (a number from 0-7), i.e. 802.1p protocol. For the packet based scheme to work however, the networking devices have to set the number in each packet they generate. This is what I am looking to see if ooma does.

So, port based prioritization is indeed handled by the router/switch, but packet based prioritization needs the cooperation of the networking equipment.

All of what I just said however is conjecture and speculation based upon what I have read. This is the first time I have ever implemented QoS!

cheers
jim
#96738 by lbmofo
Tue Jun 05, 2012 5:25 pm
I don't understand it enough but when I looked at the wiki piece, it gave me the impression that the protocol on point is used to implement QoS by MAC.

I have a D-Link DIR-825 which I can't do QoS by MAC, I had to use QoS by IP.
I've had Linksys WRT310N which I could do QoS by MAC <-- am I not using the protocol we are talking about?
#96739 by coastalcruiser
Tue Jun 05, 2012 5:33 pm
lbmofo wrote:I've had Linksys WRT310N which I could do QoS by MAC <-- am I not using the protocol we are talking about?


I would assume so. But.... how well the prioritization works may be another question, if not all the players are tagging their packets appropriately. It's one thing to organize a tea party... and quite another to get the mad hatter and everyone else to show up. ;>
-----------------

BTW - CYBERCHAT: I guess from what you were saying maybe I should be asking if the ooma telo supports VLAN tagging instead. I think I will log into my telo and look for that setting.?

ps - I find that I am constantly being logged out of this forum automatically. Makes it harder to reply to and edit posts. Is that common or should I think about a different browser (using firefox on Windows 7)/
#96740 by coastalcruiser
Tue Jun 05, 2012 5:50 pm
lbmofo wrote:I don't understand it enough but when I looked at the wiki piece, it gave me the impression that the protocol on point is used to implement QoS by MAC.

I have a D-Link DIR-825 which I can't do QoS by MAC, I had to use QoS by IP.
I've had Linksys WRT310N which I could do QoS by MAC <-- am I not using the protocol we are talking about?


I checked my oooma setup. No setting for VLAN tagging. Maybe that's not even the place to look.

Cyberchat: Do you think that maybe what ibmofo is referring to is a 3rd way that packets can be prioritized? Perhaps MAC address based prioritization looks at the packet's data to determine what priority to give it? Perhaps in the data portion of the packet their is a clue as to what type of traffic it is carrying...
#96742 by lbmofo
Tue Jun 05, 2012 6:07 pm
coastalcruiser wrote:But.... how well the prioritization works may be another question, if not all the players are tagging their packets appropriately. It's one thing to organize a tea party... and quite another to get the mad hatter and everyone else to show up. ;>

I think since the stardard we are talking about came about 1998, "Ooma is compliant" is a pretty good bet in my book. :cool:
#96744 by Cyberchat
Wed Jun 06, 2012 12:01 am
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.

The Telo appears to be designed as a stand-alone device which in addition to its VOIP functionality has some limited Router and Firewall functionality. Its focused on a single domain such as a physical netowrk for a residential network or small business network hosting from a few devices to perhaps low tens-of-devices. the Telo dosen't appear to have any ethernet switch functionality. When the OOMA Telo is installed between the Modem and the Router, Modem-->Telo-->Router (the OOMA recommended approach) the OOMA Telo's approach to QoS is simply focused on making sure that the smallest-bandwidth pipe from the ISP (usually the Upstream pipe) is configured properly such that the "Configured QoS Bandwidth is Equal-To or Less-Than the Measured ISP Upstream Bandwidth". This is to avoid any dropped packets for OOMA's Phone Calls or Voicemail when the physical network is congested (congestion could be caused by data streaming activities concurrent with VOIP traffic). By default, the Telo's QoS functionality isn't active for the Downstream ISP bandwidth since its rarely the source of call quality issues due to its typically larger bandwidth from the ISP.

A VLAN-based logical network and its QoS configurations are concerned with a much broader and more complex domain with a potential for much more network congestion due to the hosting of many more devices. Its targeted toward an Enterprise physical network which often times is geographically dispersed and which has large numbers (hundreds or thousands) of attached devices for many different functional business areas. The VLAN-network (Virtual Local Area Network) comes into play when, for example, a company wishes to provide data separation and security between network traffic from its various departments by creating separate logical networks for each of its departments dispersed throughout the enterprise, while using only one corporate physical network, which is VLAN-aware. A network administrator assigns a unique VLAN to each department. "Edge" switches on the corporate network are configured to insert an appropriate VLAN tag into all data frames arriving from equipment belonging to a given department. After the frames are transmitted on their respective VLANs through the corporate network, the VLAN tag is stripped (by another Edge switch) before the frame leaves the VLAN-aware corporate network, and is sent to its destination, which is another computer or device belonging to the same department.

Key words in the preceding paragraph are the "Edge switches" which manage the "insertion" and "stripping" of VLAN tags" into and out of all data frames, respectively.

Optionally, if the switches, Ethernet cards, and device drivers are all 802.1p compatible in this enterprise physical network, then the 802.1p PCP (Priority Code Point) field can be activated and configured to manage QoS through perhaps many network switches supporting the VLANs. For VOIP types of services where variable latency or dropped packets would cause Call Quality problems, QoS would be a very important functionality to activate in a large Enterprise network because of the potential for severe and unpredictable network congestion issues. For your network, however, with one switch, the 802.1p PCP (Priority Code Point) field-based QoS functionality would probably not be of much value since everything is being managed by the single switch. The PCP (Priority Code Point) field-based QoS functionality is targeted toward an enterprise network with many switches between the "Edge" switches.

In this VLAN scenario, an OOMA Telo would be connected (like a computer) to one of the "Edge" switches and the Telo would never see a VLAN tag in a data frame header since it would have been stripped by the Edge switch before it arrives at the Telo device. Also, the Telo's QoS functionality would be turned off (set to zero/zero) since in this VLAN scenario the Telo would be installed in a Modem-->Router/Switch-->Telo configuration.

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.

Again, this is simply my perspective on this discussion.

Who is online

Users browsing this forum: No registered users and 9 guests