> >>Packet 50 - Delay 50ms > >>Packet 51 - Delay 5ms > >>Packet 52 - Delay 5ms > >>Packet 53 - Delay 50ms > >>Packet 54 - Delay 5ms > >>Packet 55 - Delay 5ms > >> > >>Is there anyway to space them out evenly at 20ms?? > > > > > > The 20 ms is not the inter-packet timing, its the relative content of what's > > within the packet. In other words, the packet contains 20ms of encoded voice. > > > > If the inter-packet times (delays) are large, as they would seem to be > > in your example, then something else is not right. Possibly a half-duplex > > ethernet connection, something else running on the server, router buffers, > > etc. > > > > On a typical * --> C7960 local call, I generally see from 1ms to 20ms > > inter-packet delays. Seldom (if ever) anything above 20ms. > > > > I gather from your reply that there are recommendations regarding the > ethernet connection on your Asterisk server? half-duplex seems bad. > Could you elaborate a bit on that?
Yes, half-duplex ethernet connections "can" cause significant problems depending on the actual load. In very general terms, a half duplex ethernet interface can run up to about 20% utilization before collisions occur, whereas a full duplex connection can run close to 100% without dropping packets. Those rough numbers apply to both 10 meg and 100 meg ethernets. If a collision or dropped packet occurs (in a voip udp environment) there is no way to retransmit the missing/damaged packet. Missing one packet isn't a big deal, but if you have collisions and/or dropped packets, there is a very high probability that lots of packets will be dropped. If too many are dropped, you'll hear the result in the undecoded voice as choppy voice. For whatever reason, most unix systems (and MS systems for that matter) do not give you a convenient way to configure (or even check) "how" your ethernet adapter negotiates the connection. There are no official "standards" as to how the negotiation process determines half vs full, and systems get it wrong about 50% of the time. (As professional network performance consultants, we've diagnosed a very large number of problems like this in corporations around the US over the last ten years. Think in terms of a unix system trying to negotiate half vs full at the exact same time as the switch is doing the same thing "without" actually communicating to the opposite end of the cable.) If the ethernet traffic is low, no one actually notices the problem. But, as traffic increases (multiple RTP sessions, etc) the problem begins to occur and the average technical person doesn't have a clue what is really going on. What makes it difficult to identify/diagnose is that each time the system is rebooted (and each time a Cat 5 cable is disrupted), the half vs full negotiation happens again and (as mentioned) 50% of the time one end gets it wrong. Therefore the performance problem tends to come and go, and support folks typically don't associate the performance issue with the actual half/full problem. (In larger companies, the network support person might reboot a switch without the * support person knowing it, and suddenly the * support person has a problem for which he can't identify what happened.) Assuming alaw/ulaw codecs in use (about 80k bps), a half duplex 10 meg ethernet would handle roughly 20-25 rtp sessions before bumping into the problem (your milage may vary). The majority of the folks on this list seem to be running home/soho systems and would likely never run into the issue. But the heavier users will. What makes this half/full problem even more difficult to diagnose is that many of these systems have other functions running on them (eg, up2date, remote database calls, web activity, broadcasts) that can consume a fair amount of ethernet bandwidth, and the support person is so highly focused on asterisk they forget some other activity might be impacting their voip quality. Invariably, a Cat 5 cable disruption or reboot (or something else) happens at the same time the support person makes a programming or parameter change, and the person jumps to the conclusion they fixed a problem with their change when in fact the problem was with their ethernet connection. To ensure one never gets bit by the issue, simply ensure that all ethernet interfaces between the asterisk system and the sip phones are statically defined as full-duplex. (Good luck in finding the utilities that let you do that on Linux systems. They are out there, but not easy to find.) The sip phone's negotiation of half vs full is less of an issue as generally the most traffic it sees is one RTP session. But, to obtain maximum smoke and ensure highest quality, the phones should be locked at full duplex as well. Rich _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
