[Asterisk-Users] What business IP phone to use

[Rich Adamson]

Inline...

> Interesting,
> 
> So are there any sort of specifications to look for?  What your talking
> about does not sound like a managed vs unmanaged issue.  More like cheap
> crap vs half decent.  I would never want any switch to drop packets VoIP or
> not.  Does not sound like QoS could help resolve that or jitter if the
> conflicting packets both have SIP priority.

The managed vs unmanaged part of that is that you have no way to determine
what is going on within a switch if its unmanaged. For example, every time
a cat5 cable is interrupted (regardless of whether its a reboot of the device
or someone mucking with a cable) the switch port (and the device) attempt
to renegotiate the half vs full duplex. The final choice is incorrect a 
very large percentage of the time and the end result is significantly
reduced throughput. Without being able to "see" what the switch is using
you have no idea what's going on other then sometimes throughput is okay
and the next its not. (Part of that problem relates to both the device and
the switch negotiating duplex at the exact same time guessing at how the
other end is configured, which it is attempting to guess as well.)

Same basic issue with congestion... if one (or more device(s) on a switch 
attempts to save large excel spreadsheets at the same time one or more 
sip phones are communicating, you'll end up with port congestion and no 
way to "see" it. As for "I would never want any switch to drop packets",
that's a nice objective but layer-2 switches don't have any way to truly
apply back-pressure to the source devices to tell them to slow down.
That's sort of what QoS attempts to address.

There are three _basic_ ways that QoS is implemented in switches:
A) designate a QoS priority on a switch "per port" level (which implies
you can't use the dual-ethernet port on many sip phones(, or,
B) designate traffic at the udp/tcp port number level, or,
C) designate traffic by TOS bits in the IP header.

The more expensive managed switches allow the engineer to chose from
the above, AND, chose the queuing mechanism to be used for managing
the quality (and the choice of queuing mechanism _does_ have a major
impact when multiple priorities exist within a company's network.

The less expensive switches with QoS typically implement choice "A"
only.

Using some of the Cisco switches as an example, there are some
workgroup switches that only support _three_ priority levels within
the QoS mechanism, while higher end products allow seven levels.

So, you can take the typical Sys Admin approach and blame quality 
problems on all kinds of other things that the poor customer doesn't 
understand, but that you've created due to lack of knowledge and the 
inability to "see" what's happening that is impacting the network 
infrastructure. (Sometimes you _can_ luck out and come up with an
unmanaged config that is acceptable, but you'll never know why.)

Our company loves that kind of approach and it contributes heavily 
towards our net performance assessment income. :)

Of coarse, if you're selling asterisk into small environments and
_never_ sell into large networks, you might get by with your approach.

> Managed switches used to imply higher quality but I think we are starting to
> see cheap and crappy managed switches coming onto the market.  I would still
> choose a $500 unmanaged switch over a $100 managed switch.  If the switch is
> doing it's job you should never have to view what is going on in there
> anyways.

There are pletty of managed switches on the market today that do a very good
job for the $500 and under price tag. Separating the marketing/sales fluff
from the tehcnical specifications tends to take a few minutes of reading
and understanding specs though.
 
"If" asterisk had some useful mechanism to report dropped/missed packets
on an end-to-end basis (which others have recently posted about), it
would go a long ways towards managing the infrastructure and somewhat reducing
the need for switch management. However, once asterisk reported a problem
you still don't know what the source of the problem is in a multi-switch
environment nor how to fix it. (That's where products like NetIQ's voip 
assessment product (for about $25k) and switch management helps a bunch.)

> > -----Original Message-----
> > > Aha, micro seconds in networking terms is normally written 
> > usecs or us 
> > > (actually it's the greek letter mu as in ulaw) rather than ms which 
> > > are milliseconds seconds - what had me puzzled was that it 
> > was stated 
> > > that this could harm the voice path!
> > > 
> > > > The difference can also cause unnecessary delays and 
> > therefor echo 
> > > > in the path. For example, procurve switches typically have 13ms 
> > > > switching time, the high-end netgears about 21ms. As soon as you 
> > > > stack a couple of switches you are talking 26ms vs 42ms 
> > extra delay in the path!
> > > 
> > > There is then only 8 usecs between the two switches, how on earth 
> > > would this make any difference to the voice path at all? 
> > Let alone induce any echo...
> > > 
> > > Obviously the originally poster didn't understand the 
> > difference. And 
> > > based on this, he's probably advising people not to use Netgear 
> > > switches for voice, oh dear.
> > 
> > I'll jump in here to make a couple of comments relative to 
> > ethernet switches.
> > Not all switches are created equal!!!
> > 
> > If you take the cover off a switch, write down the part 
> > numbers for the chips used, and read the doc on those chips, 
> > you'll see major differences.
> > (We've actually tested several switches over the past several 
> > years in real customer's networks as well.)
> > 
> > Many entry level switches on the market have only minimal 
> > buffering for inbound and outbound packets. Its not uncommon 
> > for output buffers to be limited to one or two packets, and 
> > as a user, you can't chnage it.
> > 
> > Port congestion frequently shows up when two (or more) 
> > devices connected to a switch (assume 100 mbs for now) try to 
> > communicate via a single upstream port (assume 100 mbs for 
> > now). The instantanous offered traffic is essentially 200 
> > mbs, and the switch is expected to send that traffic out via 
> > a 100 mbs port. For those devices with minimal buffering, 
> > packets will be dropped. For newer switches with deeper 
> > buffers, "some" packets will be held up in the chip's 
> > internal queue waiting to get on the outbound port's wire. 
> > The delay in the buffer will become jitter, and depending 
> > upon exactly how many ports are contending for the outboud 
> > port, the jitter _can_ become noticable. (That _is_ one of 
> > the reasons why some switch vendors support QoS.)
> > 
> > One can talk about "wire speed throughput", etc, and it 
> > doesn't mean squat. Those are all marketing and sales words, 
> > not engineering specs.
> > 
> > There are plenty of very well known switch vendors that 
> > purchase switches from other manufacturers and put their 
> > names on the front covers. Some of those have characteristics 
> > as noted above, while others manage the buffering and queuing 
> > much better then what their marketing/sales words imply.
> > 
> > Its fairly common to see engineers in large corporate 
> > networks using workgroup switches to consolidate traffic from 
> > multiple wiring closets, and not pay any attention whatsoever 
> > to "dropped packets" in the switches.
> > That's about the time when senior mgmt intervens and asks an 
> > external company to assess their network performance to 
> > resolve the internal fingerpointing. Our company has 
> > completed many of these.
> > 
> > The _only_ way to know for sure what a switch is doing (eg, 
> > dropping pkts) is to ensure the switches have some form of 
> > network management. Even the simple Dell 2708 (eight port gig 
> > switch for $100) has "some" level of mgmt in it. Certainly 
> > not the best, but at least you can identify some issues.
> > 
> > With the pricing drops that we've all seen over the last 
> > couple of years, its fairly easy to find managed switches at 
> > very reasonable cost. I'd _never_ using unmanaged switches in 
> > any environment where critical application data flows across 
> > the net, and I'd suggest voip traffic represents "critical" 
> > traffic in all production networks.
> > 
> >