LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   Optimizing Asterisk (https://www.linuxquestions.org/questions/linux-software-2/optimizing-asterisk-769125/)

depam 11-14-2009 11:41 AM

Optimizing Asterisk
 
Hi,

I just recently setup IP04 Asterisk PABX. So far so good. I have a 512 Upload speed and have created all the users and setup the trunk. I just want to ask on what other things I need to configure to enhance the voice quality. For now, I can still feel a bit of lag and sometimes my outgoing voice is not that clear. What is jitter buffer and what benefits I can get when I use it in SIP?

Thanks and Regards,
Don

myasir_genious 11-15-2009 12:32 AM

I have installed Asterisk using yum repository and now i want to configure it. Can you tell me from where i should start because i have never used the asterisks before. Thank you

bartonski 11-15-2009 02:56 AM

Quote:

Originally Posted by depam (Post 3757021)
Hi,

I just recently setup IP04 Asterisk PABX. So far so good. I have a 512 Upload speed and have created all the users and setup the trunk. I just want to ask on what other things I need to configure to enhance the voice quality. For now, I can still feel a bit of lag and sometimes my outgoing voice is not that clear. What is jitter buffer and what benefits I can get when I use it in SIP?

Thanks and Regards,
Don

A few basics:

SIP stands for "Session Initiation Protocol", this is a text protocol similar to HTTP. This is simply used for setting up and tearing down the call. The actual voice packets are transmitted using RTP aka "Real Time Protocol". Each side of the call has its own outbound RTP stream. These are typically run across UDP; TCP/IP would introduce too much delay. UDP does not validate that packets have been received, and packets are never re-sent.

Each RTP packet typically encodes about 20ms of voice data. In a perfect data stream, packets would be sent 20ms (1/50th of a second) apart, would never be late, and would never be lost. Alas, this is not often so. Packets may come in late, may com in out of order, or not at all.

When measuring voice quality in RTP streams, you will typically measure three things:
  1. Packet Loss
  2. Latancy
  3. Jitter
Packet loss is just what it says it is. Party A sends a packet, Party B never receives it. Latancy is also not difficult to understand, it represents how long it takes packets sent by party A to be received by party B. Jitter is a measure of average variance in how often packets arrive: Party A sends packets every 20 ms, but party B may receive the individual packets late or early. Jitter is a measurement of how late or how early, on average.

The jitter buffer is a memory store which holds packets, so that even if they are a little late or early, the stream may be re-assembled in the correct order. The jitter buffer is typically set to 100ms, but it can be set higher. A jitter buffer set above 200ms will cause noticable gaps in the conversation, because there will be a cumulative 400ms delay between one person stopping speaking, and the other person responding, even if the second party responds immediately when he/she hears the first party stop speaking.

So... let's say that you have a 100ms jitter buffer set. Your friend is talking to you, but the connection is bad: let's say that there is 1% packet loss, 90ms latency, and 50ms jitter.

One percent of the packets will simply not arrive on your end. Nothing that the Jitter buffer can do about that. All packets are arriving 90ms late. This won't affect the call in and of its self, but may cause both parties to feel like they are talking via Walkie Talkie: 90ms latancy + 100ms jitter buffer = 380ms round trip, which is the better part of half a second. 50ms jitter means that on average, packets are arriving between 50 ms early and 50 ms late. This variaion in its self is putting stress on the jitter buffer, if one packet is 50ms early, and the next is 50 ms late, the jitter buffer will just be able to put the packets in order... but since jitter is an average, packets may well come in 60 ms early or late as well, and may therefore be lost, not because they do not arrive, but simply because the packet would be inserted in the stream in the wrong order, which would sound bad.

When packets are lost, the VoIP device will make a best guess as to what sound the lost packet would have contained, and put that in to the audio stream, so as to cover up drop outs. If too many packets are dropped, the device will have a difficult time re-creating the audio, and you will hear the remote party talking in a 'robot' voice, The timing and resonance will be about right, but the tamber will be more of a hum than a human voice.

You may need to play around with the size of your jitter buffer. Set too short, you'll get bad voice quality, because more packets will come in out of order outside the jitter buffer. Set too long, you will get noticable delays.

In terms of the voice quality of your connection, 512 upload should be sufficient, but again, latancy, packet loss and jitter will be the main concerns.

The company that I used to work for had a test tool available online so that its customers could test voice quality. I'm guessing that there is something similar online somewhere, and it wouldn't be too difficult to build something from scratch using Wireshark... I believe that Perl has bindings for pcap (packet capture format). Even a good long ping will give you packet loss and latancy.

If someone knows of something that's open source and already available that measures jitter, I would love to know.


All times are GMT -5. The time now is 10:32 AM.