Hi there, In other words you are maybe on 60ms and they are on 20ms or vice versa. Do a wireshark trace and see if the codecs and ptime agree on both sides otherwise you will get grabbled sounds.
On 10/29/2013 02:49 PM, Daniel van den Berg wrote: > Hi there, > > Sounds like codec ptime mismatch...what codec are you using? If you > are using g729 make sure that you and your provider is giving the same > ptime. > > On 10/29/2013 11:55 AM, Stelios Koroneos wrote: >> On Mon, 2013-10-28 at 14:29 -0400, Eddie Mikell wrote: >>> All, >>> >>> >>> The users in our organization are well, quite frankly, sick of phone >>> service that is being provided. The choppy phone calls, and drop outs >>> are detrimental to our sales force. >>> >>> >>> I've tried about everything I can think of. >>> >>> >>> Moved the asterisk server from VM machine to dedicated machine >>> More than enough bandwidth >>> Setting 802.1p = 7 >>> Set Dedicated voice traffic 35% of bandwidth. >>> >>> >>> Not sure what option would be the best >>> >>> >>> Put analog lines in the conference room to avoid the dropouts >>> - leave the sip lines in place for day to day use >>> Hire a consultant >>> Ditch the system and buy a pre-packaged system - RingCentral >>> or some such. >>> >>> >>> There are no local asterisk professionals who can help, and we are a >>> little leery of opening up our system to outside consultants. >>> >>> >>> Anyone else face the above, and finally abandoned Asterisk for a >>> commercial system? >>> >>> >>> We have 167 users. >>> I use Grandstream GXP 2100 on the desktop and Polycom ip6000 for the >>> conference rooms. >>> >>> >>> Suggestions welcome. >>> >>> >> A general rule of thump after several years with voip >> >> Voip turns out to be the "canary in the coal-mine" of a network. The >> smallest change or problem will manifest itself as a voip issue no >> matter what. >> >> >> Now to some practical advice >> >> Voip was designed for LAN's, The moment voip packets leave your lan and >> go into a WAN of any sort, it could be the source of frustration for >> many reasons. >> >> 1) Lots of routers/modems are not build to handle intense voip traffic. >> voip generates lots of small in size UPD packages. In most of the cases >> the routers/modems bridging your lan with the wan have no problem >> handling them BUT what i have found is that once you get over a >> threshold of traffic its possible the routers/modem can not cope with >> it, mainly because the large number of packets they have to process. >> In most enterprise grade routers the specs give you 2 numbers for the >> size of data the router can handle. >> total throughput and pps (packets per second). >> Usually total throughput is calculated using a packet size of around >> 1500bytes and it takes the router the same resources to process a 1500 >> bytes package as it does a 90bytes packet of a g729 call, as it just >> looks at the headers and not the payload.So yes your router can handle >> 60Mbits (of 1500byte frames) which is about 5000 packers per second but >> for voip that translates to less than 4Mbits of data (5000 packets of 90 >> bytes) >> I think you can get the picture >> >> >> 2) Because of 1) its possible that your ISP has issues, especially if >> its handling lots of voip traffic while its equipment is not optimized >> for that. >> >> >> 3) QOS and queing in general >> Whatever you do with QOS to get a better priority/quality, the dirty >> secret is, you can only control what YOU send, not what you receive. >> And even that is true till your modem/router. Once the packet is gone >> you have no control of how it will be handle by all intermediates till >> it reaches its destination. >> You have no idea if qos is honored by ALL hops and what kind of queuing >> they apply (if they do) to that port/service/qos mark >> That beeing said, its possible that you *might* have much better luck >> with sip and sip rtp than with iax rtp if your isp and all its >> interconnects bother to offer qos for rtp. >> Now for receiving it can be even harder if your isp does not provide >> correct priority queuing for the rtp stream, as latencies can build fast >> especially on "busy hours" (which happen to be the same hours people use >> their phones the most...) where people download stuff,emails etc. >> >> ping.icmp and all the other networking monitoring tools/protocols could >> be an indicator BUT its most probable that they will be handled by the >> isp and its interconnects at the higher qos priority >> The only way to see how rtp traffic is handled is to run rtp traffic. >> >> The only way around this is a "dedicated circut" MPLS or similar between >> the points of interest (i.e offices), with specific SLA which usually >> means much much higher costs. >> Finally my 2 cents for troubleshouting. >> Check the network first ! >> Find what triggers the problem. >> Is it something that happens all time regardless of traffic ? >> is it periodic ? (when bw goes over X percent, or at a specific time of >> day ?) >> Try different qos settings/priority queuing on the router >> >> > > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
