dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
2480

ctylor
@shawcable.net

ctylor to DracoFelis

Anon

to DracoFelis

Re: [Equipment] Useful Sipura tricks...

A. Trading Bandwidth for Better Sound Quality
B. Changing Your Jitter Buffer Setting


Draco asked me to add this trick to the list. Apparently all Sipuras ships with an RTP Packet Size set to 0.030 (i.e. 30ms) by default, or 33 packets per second (pps). This of course causes some degree of added latency and issues revolving around lost or discarded packets leading to greater quality loss than if a shorter interval is used.

It seems most sites in the internet recommend, or at least treat as standard, that you should usually only set the RTP Packet Size to 30ms when you use G.723.1, and to 20ms (i.e. 50 pps) when you pretty much use anything else the Sipura presently supports. 10ms (i.e. 100 pps) is also an option for the highest quality sound with the lowest degree of latency (especially when combined with a jitter buffer setting of low) when using G.711 or G.729 but at the cost of utilizing the highest bandwidth possible.

At 10ms (highest quality) / 20ms (generally recommended setting) / 30ms (Sipura default; required for G.723.1), the overall bandwidth average for ____ is:
G.711 - 126kbps / 95.2kbps / 84.7kbps
G.729ab - 70.4kbps / 39.2kbps / 28.7kbps

A full interactive chart with these codecs and several others can be found here so you can find the right balance between codec and sample period to suit your uplink capacity.

Your network jitter setting is another area to address in your attempt to reduce latency and improve audio quality. The following tip may have undesirable consequences on certain connections at certain congested times, but overall my experience with it has been very positive.

Draco offers the following summary of what the Sipura jitter settings means:
NOTE: If I understand things correctly, the "Network Jitter Level" setting doesn't control the size of the jitter buffer (which is dynamically figured out by the Sipura), but rather controls how quickly the Sipura decides it has good jitter (and thereby lowers the jitter buffer). By setting this setting to "low", you tell the Sipura to quickly assume that a low jitter is going to continue to remain. But the problem is, if the Sipura too quickly makes this assumption (and you do run into jitter), than you will get a "drop out" (or other sound artifact) as a result of the jitter. By leaving it at "high", the Sipura waits a longer time to make sure the lower jitter level really is constant, before setting the buffer to that lower level.
This is a good summary for what the setting does. I suggest you try on your connection changing it from "high" and setting it to "low". You will instantly notice a decrease in latency in echo tests (and when combined with the above 'trick' of setting the codec sample rate to 10 milliseconds will come very close to eliminating VOIP latency, echo, and cross-talking where you interrupt each other because of lag). Keeping the jitter buffer at the default of high is in my experience 'too conservative' a setting for a decent broadband connection and adds extra useless latency for no speech quality improvement. Normally, most phone calls have no/little jitter as is. And normally when there is bad jitter & packet discard issues, the cause is some program like bit torrent swamping your connection and destroying your pings to everywhere. And setting the buffer even to "extremely high" will never overcome the lag introduced by a computer on your LAN running bit torrent or a multiplayer game. A decent connection (and no bit torrent, etc.) will normally hardly have any jitter anyway and so the Sipura default for jitter correction provides unwanted dose of noticeable lag to all your conversations.

I hope you find these tricks useful.

DracoFelis
Premium Member
join:2003-06-15

DracoFelis

Premium Member

said by ctylor :

A. Trading Bandwidth for Better Sound Quality
B. Changing Your Jitter Buffer Setting


Draco asked me to add this trick to the list. Apparently all Sipuras ships with an RTP Packet Size set to 0.030 (i.e. 30ms) by default, or 33 packets per second (pps). This of course causes some degree of added latency and issues revolving around lost or discarded packets leading to greater quality loss than if a shorter interval is used.

It seems most sites in the internet recommend, or at least treat as standard, that you should usually only set the RTP Packet Size to 30ms when you use G.723.1, and to 20ms (i.e. 50 pps) when you pretty much use anything else the Sipura presently supports. 10ms (i.e. 100 pps) is also an option for the highest quality sound with the lowest degree of latency (especially when combined with a jitter buffer setting of low) when using G.711 or G.729 but at the cost of utilizing the highest bandwidth possible.

At 10ms (highest quality) / 20ms (generally recommended setting) / 30ms (Sipura default; required for G.723.1), the overall bandwidth average for ____ is:
G.711 - 126kbps / 95.2kbps / 84.7kbps
G.729ab - 70.4kbps / 39.2kbps / 28.7kbps

A full interactive chart with these codecs and several others can be found here so you can find the right balance between codec and sample period to suit your uplink capacity.

Your network jitter setting is another area to address in your attempt to reduce latency and improve audio quality. The following tip may have undesirable consequences on certain connections at certain congested times, but overall my experience with it has been very positive.
BTW: Yes, I was the one who put ctylor up to posting here. After his excellent writeup of these issues on the Voxilla.com forums, I just wanted this info preserved here (so that it would be available to those trying to learn how to best setup their LinkSys/Sipura adapters). I would just like to add a couple of points:

A) Lowering the RTP packet size (to either 0.020, or all the way down to 0.010) is a straight trade-off of using more bandwidth for better sound quality. And remember the extra 30k+ cost of using an RTP packet size of 0.010 (vs the default 0.030) is paid for ALL CODECs, even "low bandwidth" ones such as G729. In fact, setting the RTP packet size to 0.010 can more than double the normal bandwidth cost of G729 (all the way up to 70k+ bandwidth usage). While that is still lower than G711 (much less G711 with this tweak), keep that bandwidth usage in mind if/when you are on a bandwidth limited ISP.

NOTE: If your VoIP provider doesn't let you use G711 (and limits you to "lower bandwidth" CODECS, such as the previously mentioned G729), this is one way to raise the bandwidth used (and therefore also the sound quality used) by whatever CODEC(s) your provider does allow to use...

B) On the question of your "Network Jitter Level:" setting, no matter what you set it to you will be using the same amount of bandwidth. So the trade-off here, is better sound quality (and less "latency"/echo in the call) if you have a "low jitter" ISP connection, vs being more "conservative" with jitter (at the expense of possible "sound breakup").

While ctylor found a "Network Jitter Level: low" worked well for him, my tests (with my ISP) showed differently. While it is true that a setting of "low" results in the lowest possible latency/echo (which is "a good thing"), I started having problems with "stuttering sounds" (fraction of a second drop-outs of sound) when I used the "low" setting. So I boosted my setting to "medium" which helped (but didn't eliminate the effect), and eventually put it back to the default of "high" (which works reasonably well with my ISP). Granted, I lost the lower latency/echo that I gained by setting it to "low", but using a setting of "high" also caused me to lose the constant "stuttering" on my VoIP line! So lowering the "Network Jitter Level:" setting is clearly a YMMV setting. It's worthwhile trying, because it will lower latency/echo, but be prepared to set it back up if/when you start getting "stuttering" on the line...

NOTE: Yes, that means that I'm currently using trick A (more bandwidth used, by lowering my RTP packet size), but not trick B (because, in my case, lowering my jitter buffer caused problems with packet loss, which was a worse problem for our family than the latency/echo caused by the default jitter buffer size)...
ctylor
join:2006-03-15
Nelson, BC

ctylor

Member

said by DracoFelis:

said by ctylor :

While ctylor found a "Network Jitter Level: low" worked well for him, my tests (with my ISP) showed differently. While it is true that a setting of "low" results in the lowest possible latency/echo (which is "a good thing"), I started having problems with "stuttering sounds" (fraction of a second drop-outs of sound) when I used the "low" setting. So I boosted my setting to "medium" which helped (but didn't eliminate the effect), and eventually put it back to the default of "high" (which works reasonably well with my ISP). Granted, I lost the lower latency/echo that I gained by setting it to "low", but using a setting of "high" also caused me to lose the constant "stuttering" on my VoIP line! So lowering the "Network Jitter Level:" setting is clearly a YMMV setting. It's worthwhile trying, because it will lower latency/echo, but be prepared to set it back up if/when you start getting "stuttering" on the line...

NOTE: Yes, that means that I'm currently using trick A (more bandwidth used, by lowering my RTP packet size), but not trick B (because, in my case, lowering my jitter buffer caused problems with packet loss, which was a worse problem for our family than the latency/echo caused by the default jitter buffer size)...
Hi Draco, were you testing this setting using 'real world' conditions of actual phone calls with people, or mostly with IVR systems and echo tests (like FWD's)? I have difficulty replicating your stuttering/packet discard problem when the Jitter Buffer setting is on "Low" on echo tests, IVRs, or any of the phone calls I've had in the last week.

(Well not entirely true: I had a distinct problem last night when bit torrent was up and running--the echo test was almost comical! The end to end latency increased from very slight to nearly a second and half, and every fourth word (when it would finally arrive two seconds later!) would have a syllable or two get 'dropped'. That is the only stutter I've been experiencing since I've made this change on my SPA-2100.)

So I think with this one, Draco is definitely right: YMMV--your mileage may vary. I would have to guess there are two, potentially three main factors that determine whether you naturally experience a lot of network jitter with your phone calls: 1) Your ISP, 2) Your VOIP Provider and distance in ms to your sip proxy. Both 1 and 2 differ between Draco and me. Also thirdly, I am using a SPA-2100, while he is using a SPA-3000. So our test conditions do differ. But I encourage people to try it and see if they get Draco's problem of uncorrected jitter on their connection. I don't find I do on mine.
DrFillster
join:2001-12-05
Lexington, KY

DrFillster to ctylor

Member

to ctylor
This tip (see cytlor's post on page 8) should be a sticky. Thanks ctylor.

I couldn't get the RTP packet size down to 0.03; had to settle at 0.02 with latency of medium.

Made a huge difference in quality of calls.

Thanks again