Difference between revisions of "Voice quality"

From Kolmisoft Wiki
Jump to navigationJump to search
 
(2 intermediate revisions by the same user not shown)
Line 82: Line 82:
<br><br>
<br><br>
= Calls using laptop's microphone/speakers =
= Calls using laptop's microphone/speakers =
[[File:headset_microphone.jpg|200px|right]]
 
It is not possible to test call quality using laptop's microphone/speakers, because sound loop will create distortions and echo.
It is not possible to test call quality using laptop's microphone/speakers, because sound loop will create distortions and echo.


Line 91: Line 91:
* http://irockasterisk.blogspot.com.es/2011/06/voip-quality-culprits-and-thresholds.html
* http://irockasterisk.blogspot.com.es/2011/06/voip-quality-culprits-and-thresholds.html
* [http://kb.smartvox.co.uk/voip-sip/rtp-jitter-audio-quality-voip/ RTP, Jitter and audio quality in VoIP]
* [http://kb.smartvox.co.uk/voip-sip/rtp-jitter-audio-quality-voip/ RTP, Jitter and audio quality in VoIP]
* [http://blog.kolmisoft.com/route-quality-types/ Route Quality Types]

Latest revision as of 14:21, 2 October 2015

Introduction

Voice quality depends on:

  1. Network connection quality
    1. Jitter
    2. Latency (Delay)
    3. Packet Loss
  2. Codecs
  3. Phones




Troubleshooting

1. Change Provider, make call over new provider, check quality

2. Make same call from different location (with different internet provider), check quality

3. Change (soft)phone

4. Check what codec device is using

5. Change it to G729, retest

6. Check network connection status using ping command from device's location to the server's location

ping -f -c 1000 -i 0.02 -v SERVER_IP
NOTE: Change SERVER_IP to real server's IP
packet loss should be < 2% (Example: 0% packet loss)

7. Check network connection status using ping command from server's location to the device's location

ping -f -c 1000 -i 0.02 -v DEVICE_IP
NOTE: Change DEVICE_IP to real device's IP
packet loss should be < 2% (Example: 0% packet loss)

8. Use tracepath command to see connection times to hops

tracepath SOME_DISTANT_IP

9. Make recording on the server with bad call, listen to it to decide which part sounds bad, localize in which part of the network problem is

10. Check CLI for call log, look for line:

RTPAUDIOQOS: ssrc=1214214540;themssrc=2792486810;lp=0;rxjitter=0.000394;rxcount=1936;txjitter=0.000183;txcount=1975;rlp=0;rtt=0.000000

Check values lp and rlp. If they > 0, means there are lost packets. Packet Loss

Check values rxjitter and txjitter. If they > 0, means there are misplaced packets. Jitter

  • lp means lost packets comming to device from the system
  • rlp means lost packets comming from the device to the system
  • rxjitter - jitter from the system to the device
  • txjitter - jitter from the device to the system


More details: RTPAUDIOQOS Demystified

This information helps to determine quality issues in the connection between Device and the System.



Providers with poor quality codecs

Do not use G723.1, G726, GSM and similar poor quality codecs with Providers.

In worst case use G729 - it has acceptable quality.




Poor internet connection with G711 codec

When server is not in the same country as clients, and clients use phones/softphones without G729 support, such as eyeBeam, xLite and so on - then you will get poor voice quality.

This is because (soft)phones will use G711 codec, which will use 80 kbps connection.

In order to fix this problem, use only GSM and G729 codecs.




Calls using laptop's microphone/speakers

It is not possible to test call quality using laptop's microphone/speakers, because sound loop will create distortions and echo.

In order to test sound quality using softphone from laptop ALWAYS use microphone with headphones which are isolated from each other.



See also