SIP Audio Problems: Difference between revisions
mNo edit summary |
m (→Brief overview) |
||
(6 intermediate revisions by 2 users not shown) | |||
Line 19: | Line 19: | ||
! Type !! Typical Cause !! Typical fix |
! Type !! Typical Cause !! Typical fix |
||
|- |
|- |
||
| '''No audio''' || On mute?! Firewall/NAT blocking traffic || Investigate firewall/NAT/ALG |
| '''No audio''' || On mute, handset loose cable?! Firewall/NAT blocking traffic || Investigate firewall/NAT/ALG |
||
|- |
|- |
||
| '''Short silent gaps''' || Packet loss || Check internet quality |
| '''Short silent gaps''' || Packet loss || Check internet quality |
||
Line 27: | Line 27: | ||
| '''No audio after a few minutes''' || Firewall/NAT/session timeouts || Investigate firewall/NAT/ALG |
| '''No audio after a few minutes''' || Firewall/NAT/session timeouts || Investigate firewall/NAT/ALG |
||
|} |
|} |
||
* Calling *100 will play a continuous 1Khz tone - if the audio breaks up then there is a problem |
|||
= Checklist: = |
= Checklist: = |
||
== NAT == |
|||
If your phones are are on a 192.168.x.x or 10.x.x.x IP address then they will be behind a NAT router. Our [[VoIP NAT|VoIP and NAT]] page has information and tips if your phones are behind a NAT router and you have problems. |
|||
== Things to figure out == |
== Things to figure out == |
||
Line 56: | Line 62: | ||
== Things to investigate == |
== Things to investigate == |
||
* Check the quality of the internet connection |
* Check the quality of the internet connection |
||
* Calling *100 will play a continuous 1Khz tone - if the audio breaks up then there is a problem |
|||
* Check the CQM graph (if using A&A for the internet connection) |
* Check the CQM graph (if using A&A for the internet connection) |
||
* Check for other traffic on the internet connection - spikes in traffic can affect audio |
* Check for other traffic on the internet connection - spikes in traffic can affect audio |
||
Line 68: | Line 75: | ||
* (if non-A&A internet) Try a different Internet connection, including using a different ISP |
* (if non-A&A internet) Try a different Internet connection, including using a different ISP |
||
* Try non-NAT |
* Try non-NAT |
||
* |
* Disable/Enable any SIP ALG on the broadband router - if it's a feature |
||
* If it's only the incoming audio that is broken, look for the jitter buffer setting on the SIP device and increase it bit by bit. |
* If it's only the incoming audio that is broken, look for the jitter buffer setting on the SIP device and increase it bit by bit. |
||
Line 74: | Line 81: | ||
* Get a pcap and use Wireshark to decode it |
* Get a pcap and use Wireshark to decode it |
||
* Wireshark can play audio with different jitter buffer settings so you can sometimes recreate audio problems from the pcap |
* Wireshark can play audio with different jitter buffer settings so you can sometimes recreate audio problems from the pcap |
||
* Wireshark can [ |
* Wireshark can [https://wiki.wireshark.org/RTP_statistics calculate jitter and delta stats] |
||
** Packets can arrive bunched up, with gaps between, or out of order. Jitter is a measurement of this. |
** Packets can arrive bunched up, with gaps between, or out of order. Jitter is a measurement of this. |
||
** Wireshark calculates jitter as per the definition in [ |
** Wireshark calculates jitter as per the definition in [https://www.rfc-editor.org/rfc/rfc3550#page-94 RFC3550] so it uses a standard formula. |
||
** Delta is the time difference between arrival of RTP packets. Max delta is the highest gap between arrival of packets. If the max delta is greater than the jitter buffer, audio will start getting dropped. Each packet usually contains 20ms of audio, so for high enough max delta you'll start to lose audio in 20ms chunks. |
** Delta is the time difference between arrival of RTP packets. Max delta is the highest gap between arrival of packets. If the max delta is greater than the jitter buffer, audio will start getting dropped. Each packet usually contains 20ms of audio, so for high enough max delta you'll start to lose audio in 20ms chunks. |
Latest revision as of 20:58, 14 July 2023
Here is a list of things to go through when dealing with VoIP Quality issues with VoIP calls, eg: calls breaking up, garbled audio, silence or gaps in the call.
This page doesn't have all (or many) answers, but poses a whole list of things to try and do to pin-point the cause of audio problems. The aim is that by going through these points the customer and Support Staff will have a good understanding on how the problem is manifesting and what's been tried to resolve it so far. It will then make a base for further investigations.
Assumptions:
- We assume calls are working but there are audio problems - the quality of the sound on the call is not as expected
- If you have registration problems then this page isn't going to help much
- CODECs are not mentioned here, as A&A only support G7.11 A-LAW CODEC
Brief overview
Here is a very brief overview of types of audio problems, their cause and the fix. This is not exhaustive, and usually there isn't a quick fix and diagnosing and investigation is required.
Type | Typical Cause | Typical fix |
---|---|---|
No audio | On mute, handset loose cable?! Firewall/NAT blocking traffic | Investigate firewall/NAT/ALG |
Short silent gaps | Packet loss | Check internet quality |
Audio garbled | Internet quality | Check jitter and quality of internet connection |
No audio after a few minutes | Firewall/NAT/session timeouts | Investigate firewall/NAT/ALG |
- Calling *100 will play a continuous 1Khz tone - if the audio breaks up then there is a problem
Checklist:
NAT
If your phones are are on a 192.168.x.x or 10.x.x.x IP address then they will be behind a NAT router. Our VoIP and NAT page has information and tips if your phones are behind a NAT router and you have problems.
Things to figure out
Dealing with audio problems can be tricky, we need to identify as much detail about when the problems happens to aid investigation.
Question | More info |
---|---|
Exactly how is audio affected? | gaps, garbled, delayed, silence after a few minutes, etc. |
Heard on call recordings? | this feature can be enabled on the control pages Our call recording software has a large jitter buffer and rearranges out of order packets, so bear in mind it is possible for a garbled call to have a perfect call recording. |
Just incoming or outgoing calls, | ...Or on both? Knowing the direction us useful |
internal to A&A calls OK? | if you call another A&A number such as our technical support. Or is it only affecting calls that are sent outside of A&A |
BOTH mobiles and landlines | If only mobiles, is it specific to a particular carrier, eg onle EE, or Three, etc |
Are both sides of the call affected | or just one? Which side? |
If problem is outbound... | A&A Support can provide details on how to test making calls via the different upstream carriers that we use |
Things to investigate
- Check the quality of the internet connection
- Calling *100 will play a continuous 1Khz tone - if the audio breaks up then there is a problem
- Check the CQM graph (if using A&A for the internet connection)
- Check for other traffic on the internet connection - spikes in traffic can affect audio
- Check latency/jitter during a call - eg ping voiceless.aa.net.uk 1000 times and look at the min/max levels
- A&A can set up a ping graph to your IP address - Let Support staff know your IP address. This will then graph loss and latency
Things to swap/change
The aim here is to change things one by one to target in on the thing that may be the cause.
- Disable bonding, if bonding is in use (Bonding can add to jitter)
- Try just the phone on the internet connection, plugged directly in to the router - unplug/disable all other devices, disable WiFi (this also takes the LAN out of the equation as a problem on the LAN can affect the traffic)
- Try a different phone or SIP Client
- (if non-A&A internet) Try a different Internet connection, including using a different ISP
- Try non-NAT
- Disable/Enable any SIP ALG on the broadband router - if it's a feature
- If it's only the incoming audio that is broken, look for the jitter buffer setting on the SIP device and increase it bit by bit.
Advanced troubleshooting
- Get a pcap and use Wireshark to decode it
- Wireshark can play audio with different jitter buffer settings so you can sometimes recreate audio problems from the pcap
- Wireshark can calculate jitter and delta stats
- Packets can arrive bunched up, with gaps between, or out of order. Jitter is a measurement of this.
- Wireshark calculates jitter as per the definition in RFC3550 so it uses a standard formula.
- Delta is the time difference between arrival of RTP packets. Max delta is the highest gap between arrival of packets. If the max delta is greater than the jitter buffer, audio will start getting dropped. Each packet usually contains 20ms of audio, so for high enough max delta you'll start to lose audio in 20ms chunks.