Need extra help installing your Ooma Hub or Telo system? Let us know.
#95403 by Cyberchat
Tue May 01, 2012 7:13 am
coastalcruiser wrote:
.....

Thanx for all that background (not all of which I am quoting back). Interesting and informative. And I think I understand your points about VLans, but I am having trouble seeing the security benefit in this application. Would not packets to and from each telo be directed packets to a specific IP (telo <> router and router <> telo), and thus those packets would only appear on the two related ports?

.....

Yes. the QoS feature for SURE, but I also like the that the switch will let me set the speed of the port. I am not going to assume that a cluster of these phones are are all going to play well together in the same sandbox, especially with their inherent QoS disabled (set to "0"). And I am not even going to assume that the switches' QoS facility will properly manage things, given that every port will have the same priority. So I think giving the telos a "sandbox within a sandbox", if you will, by setting each port to the minimum speed required to make a quality call may better assure that all players get equal access. Of course this is all blackboard stuff for the present. Port speed may or may not end up having value, but I like having it in case it is needed. I will report back to this forum as this plays out. ;>

jim


Jim,

The security aspect changes with whatever approach you eventually end up with for deployment. If the one-tier star network of each Telo having its own port and a single unshared wire from one centralized switch works out, then in terms of voice packets they will pretty much be managed point-to-point. But you wouldn't have any security to protect from any hacker activities since all devices (Telos) would be on the same LAN segment.

If, on the other hand, because of the 100 meter (328 feet) distance limitation you discover that the most efficient deployment approach will be to use a multi-tier approach, perhaps dropping switches into the closest four residences, then radiating out from this initial four residences to two or three of the next closest residences, ..., you get the idea, then the VLANs might become even more important.

Again, in terms of VLANs, there isn't a compelling case to use them in such a small network for the classic VLAN purpose, collisions, broadcasts and broadcast storms, grouping of devices with similar requirements, etc. You probably wouldn't pay extra for the VLAN functionality unless there was some other requirement which needed it.

But security is a general requirement. (If you haven't got the drift of it yet, although in my background I've directed all of IT, I'm also an Ol' security guy)! With the VLAN approach you would have the option to empower each family to manage/police their own domain (think -- why do they put parental controls into many boxes today). Its really up to you and your community whether security is one of your requirements.

In terms of port speed, you have some good ideas. However, since on the LAN you'll have a gigabit pipe with Telo sessions producing individual capacity demands of 100 kbps or less, my thoughts are that the relatively small demands from the Telos would perhaps experience less conflict (better response time) flowing into and rattleing around in a big pipe than into a bunch of smaller artificially constricted pipes. This is based on the premise that a single car entering into a busy multi-lane highway creates less turbulence than a single car entering into a busy single lane highway.

There's probably not a big difference between these two scenarios in terms of what the User experience will be. I agree with you that its a good thing to have the port speed control if you later discover that you need it.

A lot of these discussions are academic, however, if you discover that you need to deploy a multi-tier network because of distance limitations or if you discover that this network will soon-after-deployment become multi-functional and not limited to just voice traffic.
#95412 by coastalcruiser
Tue May 01, 2012 9:22 am
Cyberchat wrote:In terms of port speed, you have some good ideas. However, since on the LAN you'll have a gigabit pipe with Telo sessions producing individual capacity demands of 100 kbps or less, my thoughts are that the relatively small demands from the Telos would perhaps experience less conflict (better response time) flowing into and rattleing around in a big pipe than into a bunch of smaller artificially constricted pipes. This is based on the premise that a single car entering into a busy multi-lane highway creates less turbulence than a single car entering into a busy single lane highway.


I see your point here. This may well be true. I tend to be cautious though, and we both know, the way things are supposed to work, juxtaposed with reality... are not always the same. With 10 telos all talking at the same instant, it will be up to the QoS algorithm on the switch to arbitrate how the packets flow to the router. It may go just peachy. But the Netgear switch gives me one arrow in my quiver, just in case someone gets piggy with all that bandwidth they think they have. ;>

jim

ps - On the VLans, yes, when it comes to potential hacking, I can see the value. :>
#95427 by Cyberchat
Tue May 01, 2012 3:09 pm
coastalcruiser wrote:
I see your point here. This may well be true. I tend to be cautious though, and we both know, the way things are supposed to work, juxtaposed with reality... are not always the same. With 10 telos all talking at the same instant, it will be up to the QoS algorithm on the switch to arbitrate how the packets flow to the router. It may go just peachy. But the Netgear switch gives me one arrow in my quiver, just in case someone gets piggy with all that bandwidth they think they have. ;>

jim

ps - On the VLans, yes, when it comes to potential hacking, I can see the value. :>


Jim,

The advantage of letting the arbitration happen at the switch is that the switch is the most efficient place for that to happen. The switch is buffered so given the relatively small rates of the Telo, (< 100kbps) there will be very little contention at the switch and it certainly won't be perceptible to anyone. Its much, much better than having collisions on a multiple-device circuit wherein a device sensing traffic must wait and try again milliseconds later. The choke point will be upstream of the switch. Given your tested througput of the internet service you should be alright even with all circuits active.

Given your Jitter measurements, it is likely going to be the major source of negative User experiences for your community and external people calling them. When conversations are happening within a room, people can take queues from visual as well as verbal/audio events to engage in and sustain a conversation. With telephone conversations their queues are limited to verbal/audio events. With too much delay, conversations get into the "Alphonso" syndrome. "You go first, ..., no you go first, ... no go ahead, ... Too much delay signals to the listening party this is a pause and he/she starts speaking only to realize they are stomping all over the continued conversation of the speaker. And so it goes ....

But, your community will probably become quickly accustomed to whatever delay exists and adjust their behavior accordingly.

One last thought which occurred to me is that when your voice system is up and operational, it will be interesting for you to discover to what extent your community will use the telephone system for intra-community communications. If it turns out that its a fairly healthy percentage, you might discover that some kind of intercom system would be a more efficient means for intra-community communications rather than conversations making the full VOIP round trip up the satellite link through carriers and back to the community.
#95439 by coastalcruiser
Tue May 01, 2012 4:57 pm
Cyberchat wrote:The advantage of letting the arbitration happen at the switch is that the switch is the most efficient place for that to happen. The switch is buffered so given the relatively small rates of the Telo, (< 100kbps) there will be very little contention at the switch and it certainly won't be perceptible to anyone. Its much, much better than having collisions on a multiple-device circuit wherein a device sensing traffic must wait and try again milliseconds later. The choke point will be upstream of the switch. Given your tested througput of the internet service you should be alright even with all circuits active.


See below excerpt from the "Ooma Telo before the router" thread in the call quality forum:

Postby snooker » Mon Apr 30, 2012 12:48 pm
... Here is my example, for modem -> Ooma -> router, with Ooma upstream QoS set to various values below. I also have the router QoS set to 5000 which affects the bandwidth measurements for my PC which is connected to the router. (I have 6400 available upstream in total).

Anyhow for this setup, measuring the bandwidth available at the router using the ShapeProbe program:
a) Ooma set to 5000: I'm seeing 4562 when not in a call and 2838 when IN a call. The difference is 1700 kbps that Ooma "consumes" for one purpose or another.


THAT is why I want to be able to set my port speeds. ;)

Cyberchat wrote:Given your Jitter measurements, it is likely going to be the major source of negative User experiences for your community and external people calling them.


Right. With the satellite at 22,000 or so feet we will have latency. Ping response times on our old hughesnet business dish ran from 800 - 2000+ ms. All over the map. The new Wildblue EXEED dish gives us ping responses contained in a tight range around 700ms. A VAST improvement, but still far higher latency than ground based systems.

But you get used to it very quickly. I just had a 20 minute test conversation with a friend who had never spoken on an IP phone via satellite. It took her just a few sentences to adjust to the inevitable delay, and then our conversation proceeded very well. What is different is that you really can't be interrupting and talking over the other person. That radically degrades the call quality (I don't know if we had a full duplex connection, or how much difference full duplex Ethernet makes with ooma). Gee... can't interrupt the other person while they talk?? This does have social implications.

This test call was over a wireless connection btw, before the new Netgear switch is installed, with the default settings of the telo in place, and the telo simply plugged into a generic switch (not direct into the satellite modem). This is very promising! :D
#95441 by Cyberchat
Tue May 01, 2012 5:15 pm
coastalcruiser wrote:
....

See below excerpt from the "Ooma Telo before the router" thread in the call quality forum:

Postby snooker » Mon Apr 30, 2012 12:48 pm
... Here is my example, for modem -> Ooma -> router, with Ooma upstream QoS set to various values below. I also have the router QoS set to 5000 which affects the bandwidth measurements for my PC which is connected to the router. (I have 6400 available upstream in total).

Anyhow for this setup, measuring the bandwidth available at the router using the ShapeProbe program:
a) Ooma set to 5000: I'm seeing 4562 when not in a call and 2838 when IN a call. The difference is 1700 kbps that Ooma "consumes" for one purpose or another.



coastalcruiser wrote:THAT is why I want to be able to set my port speeds. ;)


I understand your point but I don't believe the scenario outlined by Snooker applies to you. The timings Snooker experienced were due to the OOMA Telo device being in the critical path of communications with QoS turned on. In your scenario, the Telo will be a device at the end of the path, not a router/firewall in the critical path with QoS activated. That's the reason I suggested that you will deactivate each Telo's QoS by configuring both the upstream and downstream QoS values to zero (0).

Cyberchat wrote:Given your Jitter measurements, it is likely going to be the major source of negative User experiences for your community and external people calling them.


coastalcruiser wrote:Right. With the satellite at 22,000 or so feet we will have latency. Ping response times on our old hughesnet business dish ran from 800 - 2000+ ms. All over the map. The new Wildblue EXEED dish gives us ping responses contained in a tight range around 700ms. A VAST improvement, but still far higher latency than ground based systems.

But you get used to it very quickly. I just had a 20 minute test conversation with a friend who had never spoken on an IP phone via satellite. It took her just a few sentences to adjust to the inevitable delay, and then our conversation proceeded very well. What is different is that you really can't be interrupting and talking over the other person. That radically degrades the call quality (I don't know if we had a full duplex connection, or how much difference full duplex Ethernet makes with ooma). Gee... can't interrupt the other person while they talk?? This does have social implications.

This test call was over a wireless connection btw, before the new Netgear switch is installed, with the default settings of the telo in place, and the telo simply plugged into a generic switch (not direct into the satellite modem). This is very promising! :D


Thanks for sharing this test case with us, here in the forum. This type of feedback is the primary source of motivation for the forum participants to actively engage with the forum. I'm tucking away your experiences in my mental knowledgebase for future reference (although mental knowledgebases get a bit more shaky as years proceed) :)
#95448 by coastalcruiser
Tue May 01, 2012 6:04 pm
Cyberchat wrote:I understand your point but I don't believe the scenario outlined by Snooker applies to you. The timings Snooker experienced were due to the OOMA Telo device being in the critical path of communications with QoS turned on. In your scenario, the Telo will be a device at the end of the path, not a router/firewall in the critical path with QoS activated. That's the reason I suggested that you will deactivate each Telo's QoS by configuring both the upstream and downstream QoS values to zero (0).


You're right.
#96666 by coastalcruiser
Sun Jun 03, 2012 5:57 pm
Cyberchat wrote:I haven't personally used the Netgear GS116E PROSAFE® PLUS 16-PORT GIGABIT ETHERNET SWITCH or firewall/VPN devices in the link I sent you earlier. However, I have used multiple generations of consumer Netgear routers and switches for decades with very good success and no problems which is why I pointed the link toward Netgear. I, too, worked for decades within IT. At work, however, we pretty much used Cisco technology with a smattering of other vendor special purpose boxes for firewalls, filters, etc.

The Netgear GS116E PROSAFE® PLUS 16-PORT GIGABIT ETHERNET SWITCH might be a good choice for you. It provides:
- Network monitoring, traffic prioritization and VLAN
- 16 ports deliver up to 2000 Mbps of dedicated, non-blocking bandwidth per port
- Simple network set-up on top of plug-and-play connectivity


Hello again to Cyberchat and all the folks who have been helping me throughout this thread. My project has not been moving at lightspeed, partially due to Wildblue having continual problems keeping their new high-speed Exede satellite service up.

But I did pick up that Netgear GS116 QoS switch, and I am testing with one ooma telo online.

I have been using the switch with the default values, which turns out, according to the manual, to provide no traffic prioritization (802.1p protocol OFF, and port priority set to LOW for all ports).

I just went to program the switch and it occurs to me, since we may be sharing the 10 ooma phones that we will be connecting with a bit of other traffic, that simply turning on the 802.1p protocol on the switch would be the simplest way to employ QoS. The other way is by setting priority on a per port basis, which can be done, but if ooma supports 802.1p that may be the cleanest most flexible way to go. (and I'm putting off VLANS entirely, but only for the moment. Taking the 'building block' approach and learning what happens as I twist each dial. ;> )

But the question that came up is.... does ooma support 802.1p? To my surprise the answer is not immediately forthcoming. I did a quick google check, but got ambiguous info. I checked the QoS tips links on the ooma site. No mention of 802.1p.

So anyway, I shot an email to ooma support on this question, but thought I would post it here as well. If for no other reason than to keep this thread alive. After all, you don't see some idiot trying to connect 10 ooma phones to a satellite based Internet connection every day, so I plan on posting how this project turns out. :D

I can also post the reply from ooma support here, because again, to my surprise, when I searched this forum for the string "802.1p" I received no hits. And, I may just throw a packet sniffer on my network and have a look at an ooma packet. But I want to hear the official response too, as well as anyone here who has been down this road.

cheers
jim

Who is online

Users browsing this forum: Google [Bot] and 8 guests