[Asterisk-Users] What business IP phone to use

[mustardman29]

I have one question,

How does a large file transfer like your excel spreadsheet example, affect
communication between an Asterisk server and SIP phone?  The only possible
configuration I can think of that would cause a problem is if the client PC
is sharing the same eternet cable and therefore the same physical port on
the switch as the SIP phone.  Other than that or if your asterisk server is
also a file server (which should never be done), I don't see a problem or am
I missing something.

> -----Original Message-----
> From: Rich Adamson [mailto:radamson at routers.com] 
> Sent: Saturday, February 25, 2006 3:52 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: RE: [Asterisk-Users] What business IP phone to use
> 
> 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.)
>