Hi Chris, > I just wondered if anyone would mine posting their successful jitter > buffer settings here for me if they get a moment ??
Are you talking about settings for the iax buffer or something else? For iax.conf, I'm using: jitterbuffer=yes maxjitterbuffer=200 maxexccessbuffer=100 but that is the result of trying to minimize a voice quality problem associated with Cisco 7960 using iax connections (bug #1220). There was a vary noticible improvement in the qualtiy for that specific case when using the above verses a config with the above commented out. Still working on defining the problem though. > I've spent a few hours trying to set the jitter buffer up reasonably > logically and can definitely tell it makes a difference and can introduce > latency and echo if setup incorrectly but I can't see a good post anywhere > describing properly what the three settings actually really do or a > typical range of settings for them. I haven't attempted to read the asterisk source code, but jitter buffers "should" have zero impact on echo (theoretically). Jitter buffers are primarily used to store sufficient numbers of incoming bits/packets, and even out the flow of that data (inbound) to the receiving device in such a way as to minimize the impact of delayed or missing packets. In theory, latency isn't the issue. Jitter is the "changes" that happen to latency. Latency of 500 milliseconds is not going to impact a voip conversation, however if latency changes from 100 ms to 500 ms and then back to 200 ms (or something like that), that will be an issue and _that_ is what jitter buffers are suppose to handle. From a 20,000 foot level using those example numbers, we'd want a jitter buffer capable of handling the largest swing (eg, 500 ms - 100 ms = 400 ms buffer). Since I probably wouldn't understand * code if I did read it, I don't know if the maxjitterbuffer statement is actually specified in terms of milliseconds, bits, or whatever. Regardless, the value set is relative to what you "see" for changes in latency when doing something like "show iax2 channels". The greater the latency swings, the larger the jitter bugger. > I do roughly understand how a jitter buffer is supposed to work. > But can it help against echos heard on the lines or just the 'clicks' - > are they jitter? Echo problems are the result of inefficiecies or inadaquacies when converting from four-wire to two-wire anywhere along the end-to-end telephony path. Its really no different then the Standing Wave Ratio (SWR) in radio transmission lines. If the two-wire to four-wire conversion facility isn't 100% accurate, some amount of transmitted energy is going to be "reflected" back, and that reflected energy will be heard as an echo. Asterisk attempts to identify that reflected energy in software, and cancel out (or subtract) that amount from the incoming audio during the balance of a conversation. Since * can't afford to burn cpu cycles doing this on a constant basis (like the echo cancellers in a T1 mux's can), I believe * does a quick sampling at the start of a connection and then uses whatever it measured for the duration of that connection. The approach works, but it is not anywhere near the quality one gets from dedicated echo cancellers in mux's, etc. (I also beieve the * approach is negatively impacting transmission levels causing people to complain about low volume, etc.) In the perfect world, one should identify the root-cause for reflected energy and fix that instead of relying on echo cancellers. However, in many cases we don't have access to the location/device/hardware that "is" the root cause, so we're sort of stuck with cancelling instead. The root-cause is usually associated with improper impedence matching, poor quality components or design, leakage from tip to ground (or ring to ground), and just about any other thing that impacts one side of the tip-ring pair more then the other side (eg, impacting tip-side compared to ring-side). > Usually my cross-IAX latency is under about 35ms (commonly only 5-6ms) and > SIP latency (I know this doesn't really matter as there's no buffer for > SIP) as recorded by 'sip show peers' as about 70ms (but in reality ping I > think is about half this). > > My current setup is : > > SIP and IAX clients --> my * --> providers via IAX (one 5ms away, one 80ms > away) > > jitterbuffer=yes > dropcount=5 > maxjitterbuffer=100 > maxexcessbuffer=45 > > If anyone can post any amplification on these settings apart from what's > in iax.conf or their experiences or maybe some adjustments I should try > that'd be really really helpful. Although Mark closed bug #1220, I don't think the actual problem is fixed as yet. That particular bug really addresses a specific problem that is associated with using Cisco 7940/7960 sip phones with a iax connection. The issue "seems" to be that Cisco changed their digital signal processing method in v6 code, and this new code is sensitive to timestamps contained within the rtp hearder. When * converts iax/gsm packets to sip/rtp packets, the timestamps were apparently not being calulated properly (or something like that), and the 7960 phone effectively drops the packet(s) that have unreasonable timestamps. That causes incoming audio to stop (audio drop outs), and I believe it then impacts the outgoing rtp data stream since asterisk obtains its timing from that outgoing rtp data. As a result, both ends of the c7960 -> iax connection hear choppy audio and audio drop outs. I'm trying to use ethereal decodes to identify the issue, however its rather tough to correlate the audio problems to exact packets within a trace of thousands of packets. (My hearing verses finger response time is not as quick as packet sniffers.) Rich _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
